Re: the balance between short-term pain and longer-term viability, I’m
struck by the fact that cs:option was a rather dumb decision from an
XML standpoint. All of these can, and almost always are, represented
as attributes.
Is there any support for ditching it and instead attaching these as
attributes to the respective contexts (citation, bib, locale)?
If there is, I’ll write an XSLT to manage the conversion.
Bruce
What would be the advantage? (Only) better structured XML? Also, if we
go down this path, what about the option (no pun intended) to put the
attributes at the deepest level possible, e.g.:
hanging-indent, second-field-align and line/entry-spacing could be put
in the layout element of the bibliography.
subsequent-author-substitute and the disambiguate options in names.
All the et-al options can be put in the et-al element, or, to preserve
some background compatibility (as et-al is optional with default
behavior), one level higher in names.
I guess this is a bit of a can of worms, as some options will no
longer be global (e.g. each names-element can have different options).
Whether that is something useful I don’t know, but I thought I’d just
mention it.
Rintze
Re: the balance between short-term pain and longer-term viability, I’m
struck by the fact that cs:option was a rather dumb decision from an
XML standpoint. All of these can, and almost always are, represented
as attributes.Is there any support for ditching it and instead attaching these as
attributes to the respective contexts (citation, bib, locale)?What would be the advantage? (Only) better structured XML?
Right now, we basically use a non-standard way to indicate key-values
parameters. As a consequence, we have to go through some awkward hoops
on the validation end (in the schema), which I believe makes it
impossible to losslessly convert to XSD.
Also, if we go down this path, what about the option (no pun intended) to put the
attributes at the deepest level possible, e.g.:
It’d be worth discussing, but probably not worth the trouble.
Bruce