Re: [xsl] xsltproc and stringparam, changed behavior

Subject: Re: [xsl] xsltproc and stringparam, changed behavior
From: tom sgouros <tomfool@xxxxxxxxx>
Date: Fri, 19 Sep 2008 10:37:29 -0400
Michael Kay <mike@xxxxxxxxxxxx> wrote:

> The xsd:include template invokes the xsd:simpleType template indirectly: in
> between, the built-in template for xsd:schema is invoked.
> 
> In XSLT 1.0, built-in templates do not pass their parameters on to the
> templates that they call. So the "new" version of xsltproc is implementing
> the XSLT 1.0 specification correctly.
> 
> XSLT 2.0 changes this, so that built-in templates *do* pass their parameters
> on - but only if the parameter is actually declared as a local parameter of
> the called template (which in your case, it isn't). So the behaviour you are
> seeing would also be correct for an XSLT 2.0 processor.

I'm sure this seems an ignorant question, but how do I tell if I'm using
XSLT 1.0 or 2.0?  I can't find any mention of either in the xsltproc or
libxslt documentation or the --version message below, which makes me
think I'm in the 1.0 world, but how can I confirm that?

If it's version 1.0, then I gather that I've been relying on a "feature"
stemming from an incorrect implementation of the standard.  I'm sorry
that someone took it on themself to fix it, then.  But since that's the
case, is there some workaround people might share with me to achieve the
same end?  I'm trying to make the name of the file in which the xsd is
contained available to the output.

I did notice that if I put a parameter declaration in the xsd:simpleType
template below, that the output contains the filename set by the
xsd:include, but now it doesn't contain the filename as set by the
--stringparam. 


Many thanks,

 -tom



> 
> Michael Kay
> http://www.saxonica.com/
> 
> 
> > -----Original Message-----
> > From: tom sgouros [mailto:tomfool@xxxxxxxxx] 
> > Sent: 19 September 2008 06:00
> > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> > Subject: [xsl] xsltproc and stringparam, changed behavior
> > 
> > 
> > Hello all (especially Syd -- hi Syd!):
> > 
> > Please pardon in advance the length here, but this problem 
> > takes a bit to explain.  The issue is the behavior of 
> > parameters set with xsltproc --stringparam.  They seem to be 
> > resistant to being changed now, but they weren't in a 
> > (recent) version of xsltproc.
> > 
> > I've observed this change in behavior between two versions of 
> > xsltproc, but can not find any mention of it, possibly 
> > because I don't speak the XSL argot very well, so don't know 
> > what to call it.  Can someone look this over and tell me 
> > which is the correct behavior?
> > 
> > Test.xsl:
> > 
> > <?xml version="1.0" encoding="utf-8"?>
> > <xsl:stylesheet version="1.0"
> >   xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> >   xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
> >   <xsl:param name="filename"> </xsl:param>
> >   <xsl:template match="xsd:include">
> >     <xsl:apply-templates 
> > select="document(./@schemaLocation)/xsd:schema">
> >       <xsl:with-param name="filename">
> >         <xsl:value-of select="@schemaLocation"/>
> >       </xsl:with-param>
> >     </xsl:apply-templates>
> >   </xsl:template>
> >   <xsl:template match="xsd:simpleType">
> >     <xsl:text>Type name=</xsl:text>
> >     <xsl:value-of select="@name"/>
> >     <xsl:text>  File name=</xsl:text>
> >     <xsl:value-of select="$filename"/>
> >   </xsl:template>
> > </xsl:stylesheet>
> > 
> > s1.xsd:
> > 
> > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
> >   <xsd:include schemaLocation="s2.xsd"/>
> >   <xsd:simpleType name="OrderNumOtherType">
> >     <xsd:restriction base="xsd:string"/>
> >   </xsd:simpleType>
> > </xsd:schema>
> > 
> > s2.xsd:
> > 
> > <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
> >   <xsd:simpleType name="OrderNumType">
> >     <xsd:restriction base="xsd:string"/>
> >   </xsd:simpleType>
> > </xsd:schema>
> > 
> > Run this as:
> > 
> >                   old version
> > $  xsltproc --stringparam filename s1.xsd test.xsl s1.xsd 
> > <?xml version="1.0"?>
> > 
> >   
> >   Type name=OrderNumType  File name=s2.xsd
> > 
> >   Type name=OrderNumOtherType  File name=s1.xsd
> > 
> >                   new version
> > $ xsltproc --stringparam filename s1.xsd test.xsl s1.xsd 
> > <?xml version="1.0"?>
> > 
> >   
> >   Type name=OrderNumType  File name=s1.xsd
> > 
> >   Type name=OrderNumOtherType  File name=s1.xsd
> > 
> > 
> > With the new version, the filename parameter seems not to be 
> > reset by the xsd:include XSL code. 
> > 
> > 
> >                   old version
> > $ xsltproc --version
> > Using libxml 20614, libxslt 10111 and libexslt 809 xsltproc 
> > was compiled against libxml 20614, libxslt 10111 and libexslt 
> > 809 libxslt 10111 was compiled against libxml 20614 libexslt 
> > 809 was compiled against libxml 20614
> > 
> >                   new version
> > $ xsltproc --version
> > Using libxml 20632, libxslt 10124 and libexslt 813 xsltproc 
> > was compiled against libxml 20632, libxslt 10124 and libexslt 
> > 813 libxslt 10124 was compiled against libxml 20632 libexslt 
> > 813 was compiled against libxml 20632
> > 
> > 
> > The question: Have I been getting by, relying on incorrect 
> > behavior that has now been corrected, to my dismay?  Or has a 
> > bug been introduced in the new version of xsltproc?  That is, 
> > is this a bug fixed or a bug created?  Third option: I'm 
> > doing something subtly wrong that worked in the old code but 
> > (correctly) doesn't work in the new code. 
> > 
> > And if I'm looking at the results of fixing a bug, is there 
> > some other way to do this?  (i.e. get the name of the xsd 
> > file into the output)
> > 
> > Many thanks,
> > 
> >  -tom
> > 
> > 
> > --
> >  ------------------------
> >  tomfool at as220 dot org
> >  http://sgouros.com
> >  http://whatcheer.net
> 


-- 
 ------------------------
 tomfool at as220 dot org
 http://sgouros.com  
 http://whatcheer.net

Current Thread