Re: [xslt] xsl:element namespace query

[Daniel Veillard <veillard redhat com>]

On Thu, May 23, 2002 at 10:56:27AM +0100, Richard Jinks wrote:
> Hi
> 
> Whilst playing with my XSLT test files, I came across another odd example
> which falls into one of the fuzzy "implementation specific" parts of the
> XSLT spec. The following example concerns the way libxslt outputs namespaces
> with <xsl:element ... namespace="..."/>.
> 
> --
> Stylesheet - "54-namespaces.xsl"
> <?xml version="1.0"?>
> <xsl:stylesheet xmlns:xsl='http://www.w3.org/1999/XSL/Transform'
> version="1.0">
> <xsl:output method="xml" indent="yes"/>
> 
> <xsl:template match="/">
>   <AAA>
>     <xsl:element name="BBB"
> namespace="http://zvon.org/xslt";>111</xsl:element>
>     <xsl:element name="{//el}" namespace="{//ns}">
>       <xsl:value-of select="//val"/>
>     </xsl:element>
>     <xsl:element name="qqq:{//el}" namespace="{//ns}">
>       <xsl:value-of select="//val"/>
>     </xsl:element>
>   </AAA>
> </xsl:template>
> 
> </xsl:stylesheet>
> 
> --
> XML File - "54-namespaces.xml"
> <?xml version="1.0"?>
> <AAA author="nicmila@idoox.com">
>      <ns>http://zvon.org/xslt</ns>
>      <el>XXX</el>
>      <attr>ww:eee</attr>
>      <val>555</val>
> </AAA>
> 
> --
> xsltproc results:
> C:\libxml\libxslt-1.0.17.win32\util> xsltproc 54-namespaces.xsl
> 54-namespaces.xml
> <?xml version="1.0"?>
> <AAA xmlns:ns1="http://zvon.org/xslt";>
>   <ns1:BBB>111</ns1:BBB>
>   <ns1:XXX>555</ns1:XXX>
>   <ns1:XXX>555</ns1:XXX>
> </AAA>
> 
> --
> Saxon 6.5.1 results
> C:\libxml\libxslt-1.0.17.win32\util>saxon 54-namespaces.xml
> 54-namespaces.xsl
> <?xml version="1.0" encoding="utf-8"?>
> <AAA>
>    <BBB xmlns="http://zvon.org/xslt";>111</BBB>
>    <XXX xmlns="http://zvon.org/xslt";>555</XXX>
>    <qqq:XXX xmlns:qqq="http://zvon.org/xslt";>555</qqq:XXX>
> </AAA>
> 
> --
> MSXSL4 results
> C:\libxml\libxslt-1.0.17.win32\util>msxsl 54-namespaces.xml
> 54-namespaces.xsl
> <?xml version="1.0" encoding="UTF-16"?>
> <AAA>
> <BBB xmlns="http://zvon.org/xslt";>111</BBB>
> <XXX xmlns="http://zvon.org/xslt";>555</XXX>
> <qqq:XXX xmlns:qqq="http://zvon.org/xslt";>555</qqq:XXX>
> </AAA>
> 
> 
> My query stems from not expecting libxslt to be this clever and merge the
> namespaces together into one namespace declaration on the parent AAA
> element. I was expecting the more literal "simple" output (as with Saxon and
> MSXSL) with the namespace declaration sat on the elements they were declared
> with in the stylesheet.

  I can't recall how/why the namespace declaration got moved that way.
One thing is sure, when generating a output node in the tree within a namespace
if that namespace has already a declaration in scope, then libxslt will reuse
it an not regenerate a declaration again. That's something which I think makes
sense, and would not like it to be changed.

> Now I know that what libxslt outputs isn't wrong in that the children
> elements of AAA are in the correct namespace, and it is still working inside
> the XSLT spec - it just isn't what I'd expected. I'm a touch concerned that
> it is losing some information by overriding the prefix "qqq:" specified for
> the third element, but as the XSLT spec says that the XSLT processor is
> allowed to do this, I don't have much cause to complain.
> 
> Is there an easy way of making libxslt handle outputting namespace nodes in
> the same manner as the other processors, or would I need to modify lots of
> code to make it work?

  I honnestly don't know, I wrote this one year ago ! If you can spot why
the namespace declaration is generated on the parent element, then that
is probably very easy to change/fix.

> On a related node, if I did have to modify the code would you be interested
> in reflecting the change back into libxslt, or are you happy with the way it
> works / have a reason for preferring things as they are?

  With the revision 1.0 of the namespace spec I don't see how this
can be a problem, but with 1.1 where prefix scope can be cancelled at 
a given node level, then the fact of up'ing the declaration one level
up can become a serious problem, and from that point of view that ought
to be fixed to be future proof.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/