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

RE: Extension attributes

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Wed, 21 Nov 2001 13:49:16 +0100
Message-ID: <DFF2AC9E3583D511A21F0008C7E6210622B81C@softwareag.com>
To: "'Jeni Tennison'" <jeni@jenitennison.com>, xsl-editors@w3.org, w3c-xsl-wg@w3.org
A personal reaction:

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

Mike Kay

> -----Original Message-----
> From: Jeni Tennison [mailto:jeni@jenitennison.com]
> Sent: 19 November 2001 16:19
> To: xsl-editors@w3.org; w3c-xsl-wg@w3.org
> Subject: Extension attributes
> Hi,
> There are certain attributes in the XSLT namespace that can be placed
> on any literal result element (e.g. xsl:exclude-result-prefixes,
> xsl:use-attribute-sets).
> Currently, though, if you specify an extension attribute on a literal
> result element, in a namespace other than the XSLT namespace, it
> always gets added to the result tree [Section 7.1.1].
> I think it would tie in better with the behaviour of the XSLT
> attributes and with extension elements if the effect of
> extension-element-prefixes/xsl:extension-element-prefixes were
> extended such that attributes with extension namespaces are not added
> to the result tree.
> I haven't got a real use case for it, but the fact that there are such
> attributes in the XSLT namespace implies that it's possible to think
> of extension attributes for xsl:element, and hence for literal result
> elements, that you wouldn't want to include in the result tree.
> Cheers,
> Jeni
> ---
> Jeni Tennison
> http://www.jenitennison.com/
Received on Wednesday, 21 November 2001 07:49:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:22 UTC