- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Wed, 21 Nov 2001 08:17:04 -0500 (EST)
- To: "Kay, Michael" <Michael.Kay@softwareag.com>
- CC: xsl-editors@w3.org, w3c-xsl-wg@w3.org
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 UTC