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 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Delete element except one, G. Ken Holman | Thread | Re: [xsl] Namespace-alias using #de, David Carlisle |
RE: [xsl] Incremental Numbering, G. Ken Holman | Date | RE: [xsl] Incremental Numbering, Mark Williams |
Month |