Re: [xslt] Namespace problem

On Mon, Apr 30, 2001 at 03:42:31PM +0000, Bjorn Reese wrote:
> The attached files triggers a problem with namespaces.
> I believe that the problem is found in pattern.c / xsltCompileStepPattern
> in the line that says (actually, there are three of these lines, and the
> problem may pertain to all of them, although I have only experienced it
> for the last of the three lines)
>   ns = xmlSearchNs(ctxt->doc, ctxt->elem, prefix);
> There seems to be a mismatch between the two first parameters and the
> last. The two first parameters are pointing to data within the xsl
> file, but the prefix parameter contains the namespace from the xml
> file. So it tries to find the 'ns' namespace in the xsl file, starting
> from the <xsl:template match='ns:root'> line.

  I think this is actually a problem in the XSL (or a small
misunderstanding of the way the namespace based selectors works):

> This was tested against the latest CVS version.
> <xsl:stylesheet
>  xmlns:xsl="";
>  version="1.0">
> <xsl:output method="text"/>
> <xsl:template match="ns:root">

  What's happen here is the following:

orchis:~/XSLT/tests/general -> xsltproc bug-18-.xsl ../docs/bug-18-.xml 
xsl: pattern, no namespace bound to prefix ns

  the "ns" prefix is used in a context where it is not defined.

Section 2.4: on Qualified Names

  "If it has a prefix, then the prefix is expanded into a URI reference
   using the namespace declarations in effect on the attribute in which
   the name occurs."

the ns value has to be defined in the stylesheet, starting with
adding the declaration on the xsl:stylesheet should do the trick:


(actually using xmlns:ns2="whatever" and <xsl:template match="ns2:root">
 should lead to the same result. From an XML point of view the prefix
 doesn't really exist only the URI reference to which it is bound counts).

However even with this I still don't get the expected behaviour:

orchis:~/XSLT/tests/general -> xsltproc bug-18-.xsl ../docs/bug-18-.xml 

orchis:~/XSLT/tests/general -> 

Running it with -v gives the reason:

orchis:~/XSLT/tests/general -> xsltproc -v bug-18-.xsl ../docs/bug-18-.xml 
xsltParseStylesheetFile : parse bug-18-.xsl
Added namespace: xsl mapped to
Added namespace: ns mapped to whatever
xsltPrecomputeStylesheet: removing ignorable blank node
xsltParseStylesheetProcess : found stylesheet
xsltCompilePattern : parsing 'ns:root'
added pattern : 'ns:root' priority 1.000000
xsltCompilePattern : parsing '/'
added pattern : '/' priority 0.000000
parsed 2 templates
Initializing keys on ../docs/bug-18-.xml
Evaluating global variables
xsltProcessOneNode: applying template for /
xsltApplyOneTemplate: copy text 

orchis:~/XSLT/tests/general -> 

  The XSLT processing is started with the root node (i.e. the document node
not the element child of the document), hence the / templates kicks in 
and exits (since there is no apply-templates) before the processor tries
to find a template for the ns:root element.

  I do think that the namespace selection actually works as expected:

orchis:~/XSLT/tests/general -> cat bug-18-.xsl

<xsl:output method="text"/>

<xsl:template match="ns2:root">

<xsl:template match="ns:root">

orchis:~/XSLT/tests/general -> cat ../docs/bug-18-.xml 
<ns:root xmlns:ns="whatever">
orchis:~/XSLT/tests/general -> xsltproc bug-18-.xsl ../docs/bug-18-.xml 

orchis:~/XSLT/tests/general -> 

  I also added a test 19 where the order of the templates ns2:root and
ns:root are interchanged to be sure that it wasn't due to the ordering
in which they appear in the stylesheet :-)


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml Gnome XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]