xsl-list
[Top] [All Lists]

RE: [xsl] Namespace-aliasing and excluded namespaces

2006-05-10 12:16:20
Hi, 

-----Original Message-----
From: Michael Kay [mailto:mike(_at_)saxonica(_dot_)com] 
Sent: Wednesday, May 10, 2006 8:46 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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(_dot_)buchcik(_at_)4commerce(_dot_)de] 
Sent: 10 May 2006 18:49
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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

--~------------------------------------------------------------------
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>
--~--