RE: xsltproc and stringparam, changed behavior

xsltproc is an XSLT 1.0 processor, but you can always find out using

system-property('xsl:version')

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

Declare the parameter <xsl:param name="filename"> in each template, and pass
the values through explicitly (which means writing an explicit template for
xs:schema).

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

First, use different names for the global parameter and the local
parameters, to avoid confusion.

Write a template for match="/"

<xsl:template match="/">
  <xsl:apply-templates>
  <xsl:with-param name="fileName" select="$inputParam"/>
  </xsl:apply-templates>
</xsl:template>

so that when you start processing, the externally-supplied value gets passed
to the first template, and thereafter gets passed all the way down.

Michael Kay
http://www.saxonica.com/

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