The above is less elegant and easily controlled from a purely XML
standpoint, but it probably fits better non-XML programming
environments (indeed, the thinking is partly motivated by working on
the port to Ruby, where I have objects that "look" something like the
above), and would be easier to integrate into existing styling systems
(e.g. ODF). It's also more flexible.
The idea would be to use conventions on the name attributes to signal
hierarchy. The hyphen would denote a relation. So, for example,
"container-title" does the same thing as the existing nested elements.
Likewise for the publisher-* names.
I add the formatting-group element to retain the ability to group
formatting where needed, but leave it totally flexible what would go in
Any opinions? This would be a kind of radical change, and if I do it, I
might as well get it over with quickly and not look back. Not
surprisingly, I'm reluctant to do so without a few votes of confidence!
Maybe I'm being a little crazy!
Re: [dev-biblio] another, more radical, possibility
On Feb 5, 2006, at 8:58 PM, pt wrote:
> Looks ok to me, but have you considered whether an attribute is the
> best way to represent the prefix and suffix? What if they actaully
> require some formatting in some environments?
I originally had them as elements, but a long time back decided to
change to attributes. My reasoning was that a) I can't really imagine
needing that, and b) allowing it adds complexity all around. Imagine,
for example, creating a GUI editor for it.
Also, ODF has prefix and suffix attributes in some places already.
That said, it's not like I'm 100% confident in these decisions. I think
they involve design trade-offs, and am not always sure I'm choosing
right (which is why these emails!).
On Feb 7, 2006, at 9:50 AM, Matthias Basler wrote:
> Using usual XML parsers as I know them from Java it is not easier or
> difficult to parse or write elements than attributes.
The issues I'm concerned about (beyond file size, which is
substantially smaller now) are not parsing or serializing, so much as
mapping to native objects, and GUI implementations. Beyond OOo, say one
I may be needlessly worrying about this; am not sure.
> Anyway, my opinion is NOT to use such "flattened" layout.