W3C home > Mailing lists > Public > xsl-editors@w3.org > October to December 2001

Re: Extension attributes

From: Jeni Tennison <jeni@jenitennison.com>
Date: Wed, 21 Nov 2001 08:17:04 -0500 (EST)
Message-ID: <3013417082.20011121131656@jenitennison.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:52 GMT