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.