W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2003

RE: XSLT 2.0 xsl:attribute vs xmlns

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Tue, 21 Jan 2003 13:38:53 +0100
Message-ID: <DFF2AC9E3583D511A21F0008C7E621060453DF95@daemsg02.software-ag.de>
To: Mike Brown <mike@skew.org>, public-qt-comments@w3.org

> In XSLT 2.0 (15 November 2002 WD), ERR086 states the 
> following for xsl:attribute's evaluated 'name' attribute 
> value template:
>   It is a dynamic error if the effective value is not a QName 
>   or is the string xmlns. The processor must either signal the 
>   error, or must recover by not adding the attribute to the
>   result tree.
> This is the same as in XSLT 1.0.
> That section goes on to say that in the case where the 
> namespace is not null 
> and 'xmlns' is the preferred prefix (as indicated in the 
> xsl:attribute 'name' 
> attr), that a generated prefix must be used instead.
> It seems like the spec is confusing serialization issues (concern for
> prefixes) with XPath data model issues (whether it's OK to 
> have an attribute with a certain expanded-name).
> I suggest moving the serialization concerns to the section on 
> XML output, or at least mention them there.

Logically, you're probably right. However, the spec is trying to make it
clear to readers that you can't use xsl:attribute to create namespace
declarations. If this were moved elsewhere, people looking up the spec of
xsl:attribute would be likely to miss it. This is essentially an editorial
judgement - we try to balance being formal and logical with being helpful to
the reader.

Actually, the selection of a prefix for element and attribute names is
effectively done as part of the namespace fixup process, not as part of
serialization. The fixup process generates namespace nodes (i.e. prefix=uri
pairs) for all required namespace URIs. The serializer is free to select a
prefix if there is more than one available, but it can't dream up new ones.
This has changed since XSLT 1.0, and is necessary because result trees (in
the guise of temporary trees) are now visible to the application.

> Also, I'm not entirely convinced that there should be an 
> outright ban on the creation of an attribute with local-name 
> 'xmlns' in no namespace; the XPath data model does not 
> explicitly forbid it, and if I'm producing non-XML 
> output from the result tree, it might be allowable. 

We generally take the position that it should not be possible to create a
result tree that cannot be serialized as well-formed XML. This is why, for
example, we don't allow a comment node to contain "--", and why we don't
allow two attributes on the same element to have the same name.

Michael Kay
Software AG
Received on Tuesday, 21 January 2003 07:39:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:11 UTC