Hi Mike, > I can't see any particular problem with this change (there is a > theoretical backwards incompatibility, but a very minor one): but > nor can I see any pressing need for it. All the examples that I've > seen of vendor-supplied extension attributes apply to XSLT > instructions, not to literal result elements. Fair enough; it just seemed a bit inconsistent. I did think of something like this as a use case: It would be feasible for an implementer to come up with an extension attribute on xsl:element called 'schema:type'. This gives the name of a type from a schema and forces the value of the generated element to be valid according to that type. If the generated content *isn't* valid, then the processor adds an xsi:nil attribute to the element and leaves it empty. Or a 'my:default-value' extension attribute on xsl:element that gives the element the default value if the content of the xsl:element doesn't return a value. If you're not allowed extension attributes on literal result elements, then the only way to create elements using these facilities is with xsl:element, which is long winded. But I'm not particularly fussed. It was just something that struck me as I was thinking about extension elements and attributes. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/Received on Wednesday, 21 November 2001 13:52:00 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:52 GMT