RE: [xsl] Namespace-alias using #default with no default namespace in scope

Subject: RE: [xsl] Namespace-alias using #default with no default namespace in scope
From: "Buchcik, Kasimier" <k.buchcik@xxxxxxxxxxxx>
Date: Fri, 12 May 2006 11:37:37 +0200
> -----Original Message-----
> From: Michael Kay [mailto:mike@xxxxxxxxxxxx]
> Sent: Thursday, May 11, 2006 10:49 PM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: [xsl] Namespace-alias using #default with no
> default namespace in scope
> > This is an XSLT 1.0 issue.
> >
> > With XSLT 2.0 processors, a value of "#default" either for
> > the stylesheet-prefix or result-prefix of an
> > xsl:namespace-alias will raise a static error.
> Actually, no: we decided to change that because of
> compatibility concerns.

Ah! Is a more recent version of the XSLT 2.0 spec available
somewhere? I'm currently reading,
which says: "W3C Candidate Recommendation 3 November 2005".

I already searched the spec for something like "#none" to be
specified if one wants to move elements from/to no namespace.
Using a "#none" would be clearer in my opinion; additionally
safer, since, if stylesheets are generated by e.g. multiple
transformation steps, one might not know at the end if a
transformation step hasn't decided to generate a default
namespace declaration on a relevant element like xsl:stylesheet;
thus a "#default", originally intended to refer to no namespace,
might incorrectly refer to an existing default namespace in the end.

> Not with the 1.0 spec, which has nothing to say on the
> subject, but with 1.0
> implementations and applications. See
> I suspect you've researched the behaviour of 1.0 processors
> for this case
> more thoroughly than we did!

Results for the stylesheet at

- MSXML .NET and Libxslt:

<?xml version="1.0"?>
<err:out xmlns:err="ns://">

- Xalan-J still raises a NullPointerException.

Back again to my previous example: I think the problem with
this stylesheet is that it has a default ns-declaration on
one of the literal result elements.

It seems that the processors do one of the following:

1) Break the rule that every non-excluded ns-declaration
   has to be copied to the result and don't copy the default
   ns-declaration (MSXML .NET).
2) Use the rules for namespaces in XML 1.1, undeclare the
   prefix "foo" with xmlns:foo="" and use this prefix for
   the result elements (Saxon 6.5.3).
3) Raise an error, since if such a scenario produces an
   unresolvable namespace clash.
   I think Saxon 8.1.1 is doing this, since it reports:
   "Cannot output a namespace node for the default namespace
   when the element is in no namespace"
4) Do something unexpected (Libxslt)
5) Raise a NullPointerException (Xalan-J)

I like the version 2): it looks like a robust mechanism to avoid
namespace clashes.

I also like 3): I wouldn't mind moving the responsibility for
the mess to the author of the stylesheet.

Since Libxml2/Libxslt does not support XML 1.1 yet, I think
3) will be the way to go. But if anyone has more insight here,
I would be glad to hear about other options.

One additional observation:

If we have:

<xsl:stylesheet ... xmlns:from="urn:test:from" xmlns:to="urn:test:to">

  <xsl:namespace-alias stylesheet-prefix="from" result-prefix="to"/>

Some processors prefer using the "from" prefix for the resulting
elements and some processors use the "to" prefix.

Couldn't there be a rule, or at least a suggestion in XSLT 2.0 to use
either the literal namespace prefix or the target namespace prefix?
I'm aware that both versions are equal in the end wrt to namespace
semantics; but, for a stylesheet author: not knowing what the result
will look like might be irritating.



Current Thread