I agree that there's no reason to prefer the attribute value over the content if you're operating in RELAXNG. My preference is probably coloured by the fact that the current ODD processor doesn't translate the macroRef properly: it produces "CDATA" in the DTD rather than "#PCDATA". I havent checked to see what it does for XSD but that's probably defective too. On 22/01/16 13:13, Syd Bauman wrote:
I have no objection: since we never plan to put markup inside the value of <param> (right?), whether it is an attribute value or content does not matter at all. That said, I cannot fathom why it is easier to enforce that the value of an attribute be macro.xpath vs the content an element be macro.xpath.
element param { attribute value { macro.xpath } }
element param { macro.xpath }
or
<attDef ident="value"> <datatype maxOccurs="1" minOccurs="1"> <rng:ref name="macro.xpath"/> </datatype> </attDef>
<content> <rng:ref name="macro.xpath"/> </content>
or, if using PureODD, change <rng:ref> to <macroRef>.
Either way, neither one seems particularly more difficult to do than the other.
The <param> element currently declares its content to be "macro.xpath" -- i.e. it can contain only an XPath.
It would be a lot easier to enforce this constraint if the content were supplied as an attribute, e.g. "value"
so, eg, instead of
<param name="foo">@bar</param> <param name="default">corr</param> <param name="lang">ancestor::*/@xml:lang</param> <param name="place">'foot'</param>
I suggest
<param name="foo" value="@bar"/> <param name="default" value="corr"/> <param name="lang" value="ancestor::*/@xml:lang"/> <param name="place" value="'foot'"/>
Anyone got strong feelings against this change? The @place example looks a bit dodgy, but otherwise it seems a fairly benign enhancement.