W3C home > Mailing lists > Public > xsl-editors@w3.org > April to June 2001

Clarification request for xsl:element

From: <David_Marston@lotus.com>
Date: Fri, 27 Apr 2001 16:04:42 -0400 (EDT)
To: xsl-editors@w3.org
Message-ID: <OFF70A1A35.EA39610E-ON85256A3B.006A6B05@lotus.com>
The XML Namespaces document defines a namespace declaration in section 2,
defining "namespace name" thusly:
"The attribute's value, a URI reference, is the namespace name identifying
the namespace."
It goes on to say:
"If the attribute name matches PrefixedAttName [xmlns:NCName], then the
NCName gives the namespace prefix.... In such declarations, the namespace
name may not be empty."
Summing up, the following is disallowed as a namespace declaration:

Given that, what behavior should result from the XSLT template instruction
<xsl:element name="pref:localpart" namespace="">
(When the namespace attribute is non-null, the favored behavior seems to be
to re-assign the namespace associated with "pref" to provide both the
requested prefix and namespace, but that behavior is not required.)

The most that we can gather from subsection 7.1.2 of XSLT 1.0 is:
"If the namespace attribute is present, .... If the string is empty, then
the expanded-name of the element has a null namespace URI."
It does not require that an error be raised for
<xsl:element name="pref:localpart" namespace="">
nor does it say whether a processor is allowed to raise an error. The Xalan
team is contemplating an error for this situation, on the grounds that the
stylesheet writer should not have the prefix in the requested name. We
don't want to emit XML that violates the rules of XML Namespaces.

If raising an error is not allowed, please issue an erratum that says that
the correct action is to produce an element whose name is the local part of
the requested name. If raising an error is allowed (at developer's
discretion) or even required, please issue an erratum to that effect.
.................David Marston
Received on Saturday, 28 April 2001 02:55:14 UTC

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