-----Original Message-----
From: Michael Kay [mailto:mike(_at_)saxonica(_dot_)com]
Sent: Thursday, May 11, 2006 10:49 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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 http://www.w3.org/TR/xslt20,
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
http://www.w3.org/Bugs/Public/show_bug.cgi?id=2613
I suspect you've researched the behaviour of 1.0 processors
for this case
more thoroughly than we did!
Results for the stylesheet at
http://www.w3.org/Bugs/Public/show_bug.cgi?id=2613:
- MSXML .NET and Libxslt:
<?xml version="1.0"?>
<err:out xmlns:err="ns://www.error.com/">
<banana>
<err:yyy/>
</banana>
</err:out>
- 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.
Regards,
Kasimier
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--