RE: [xsl] xmlns created literally

["Michael Kay" <mike@xxxxxxxxxxxx>]

> > I think the output that shows the namespace URI 
> percent-encoded is wrong.
> > I can't see any justification for percent-encoding a namespace URI 
> > under any circumstances.
> 
> According to "Namespaces in XML 1.0 (Second Edition)", "An 
> XML namespace is identified by a URI reference [RFC3986]". 
> '{' and '}' are not valid characters in a URI according to RFC3986.
> 
> Switching to XML 1.1 does not make '{' or '}' acceptable either. 
> "Namespaces in XML 1.1 (Second Edition)" says "An XML 
> namespace is identified by an IRI reference [RFC3987]". 
> RFC3987 section 3.1 "Mapping of IRIs to URIs" says:
> 
>    Systems accepting IRIs MAY also deal with the printable 
> characters in
>    US-ASCII that are not allowed in URIs, namely "<", ">", '"', space,
>    "{", "}", "|", "\", "^", and "`", in step 2 above.
> 
> So '{' and '}' are not valid characters in an IRI either.

> It also seems that in both 
> cases the XML parser has accepted the invalid XML without any 
> error or warning.
> 

Section 8 of Namespaces 1.1 says: To conform to this specification, a
processor MUST report violations of namespace well-formedness, with the
exception that it is not REQUIRED to check that namespace names are legal
IRIs. Namespaces 1.0 has essentially the same rule.

Note also, Namespaces 1.1 says: "Because of the risk of confusion between
IRIs that would be equivalent if dereferenced, the use of %-escaped
characters in namespace names is strongly discouraged. "

Given that XML parsers appear to have universally decided to take advantage
of the freedom to allow any string as a namespace name, we had to tread very
carefully in XSLT because users would get upset if their documents got
through the XML parser only to be rejected by the XSLT processor. We do say,
for xs:element:

[ERR XTDE0835] It is a non-recoverable dynamic error if the effective value
of the namespace attribute is not in the lexical space of the xs:anyURI data
type.

However, that's just a bit of nifty buck-passing, because the XSD 1.0 spec
is rather ambiguous about the lexical space of xs:anyURI, and XSD 1.1 has
cut the Gordian knot by saying it's any character string.

Michael Kay
http://www.saxonica.com/