Altova Mailing List Archives


RE: [xsl] Namespace-aliasing and excluded namespaces

From: "Buchcik, Kasimier" <k.buchcik@------------>
To:
Date: 5/10/2006 7:16:00 PM
Hi,

> -----Original Message-----
> From: Michael Kay [mailto:mike@xxxxxxxxxxxx]
> Sent: Wednesday, May 10, 2006 8:46 PM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: [xsl] Namespace-aliasing and excluded namespaces
>
> namespace-alias in 1.0 is underspecified. In particular,
> there is no text in
> the spec that describes its interaction with excluded namespaces -
> specifically, it doesn't tell you whether to test a namespace
> URI against
> the list of excluded namespaces before or after aliasing it.
> You just have
> to make up the rules as you go along. Libxslt seems to be
> testing it neither
> before nor after aliasing - since the rules for namespace
> aliasing override
> some of the things said in the section on excluded

The problem with Libxslt is that, wrt to namespace exclusion, it
somehow processes the literal result elements, which are the
children of an xsl:template, differently than literal result
elements deeper in the subtree of an xsl:template. The latter
do work fine - or at least better.

> namespaces, I don't think
> one can argue that that's not one possible reading of the

I'd rather like to change this in Libxslt; I don't think
that this behaviour was intended.

> spec. In any case,
> an XSLT 1.0 serializer is allowed to add any namespaces it likes at
> serialization time.

Ah, good to know.

> We were well aware when we defined the more precise 2.0 rules
> for namespace
> aliasing that there were many edge cases that weren't well
> covered by the
> 1.0 spec, and that we couldn't therefore guarantee backwards
> compatibility
> with existing implementations.

Yes, I'm currently reading those definitions; this makes things
clearer for XSLT 2.0 processors.
Comparison against Xalan and Saxon 6.5.3 will be the way to go
when refactoring namespace-aliasing/namespace-exclusion in Libxslt.

> I wouldn't particularly trust Saxon 8.1.1 on this - it's a rather old
> release and the spec has been refined in many corner cases -
> but 8.7.1 is
> doing the same, outputting all three namespace bindings.
>
> Michael Kay
> http://www.saxonica.com/

OK. Thanks for the info!

> > -----Original Message-----
> > From: Buchcik, Kasimier [mailto:k.buchcik@xxxxxxxxxxxx]
> > Sent: 10 May 2006 18:49
> > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> > Subject: [xsl] Namespace-aliasing and excluded namespaces
> >
> > Hi,
> >
> > Can someone confirm that the stylesheet below should generate
> > the following?
> >
> > 1) With XSLT 1.0 processors (with MSXML.NET, Xalan-J, Saxon 6.5.3):
> >   <foo/>
> >
> > 2) With XSLT 2.0 processors (run with Saxon 8.1.1):
> >   <foo xmlns:ext="urn:test:ext" xmlns:ext-literal="urn:test:ext"
> > xmlns:ext-target="urn:test:ext"/>
> >
> > For 2) the relevant pieces of spec seem to be:
> >
> > "A namespace node whose string value is a target namespace
> > URI is copied to the result tree, whether or not the URI
> > identifies an excluded namespace."
> > "In the event that the same URI is used as a literal
> > namespace URI and a target namespace URI, the second of these
> > rules takes precedence."
> >
> > Libxslt seems to be confused by the aliasing of the same
> > namespaces, and
> > reports:
> > <foo xmlns:ext="urn:test:ext" xmlns:ext-literal="urn:test:ext"/>
> >
> > Scenario:
> >
> > <?xml version='1.0'?>
> > <xsl:stylesheet version="1.0"
> >   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> >   xmlns:ext-literal="urn:test:ext"
> >   xmlns:ext-target="urn:test:ext"
> >   extension-element-prefixes="ext-target">
> >
> >   <xsl:namespace-alias stylesheet-prefix="ext-literal"
> > result-prefix="ext-target"/>
> >
> >   <xsl:template match="/">
> >     <foo xmlns:ext="urn:test:ext"/>
> >   </xsl:template>
> >
> > </xsl:stylesheet>
> >
> > Regards,
> >
> > Kasimier

[...]

Regards,

Kasimier

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.