Re: [xsl] xsltproc and stringparam, changed behavior

[tom sgouros <tomfool@xxxxxxxxx>]

Michael:

Thank you for this help.  In my example XSL, this is now working, by
including this:

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

  <xsl:template match="xsd:schema">
    <xsl:param name="sourcefile"/>
    <xsl:apply-templates>
      <xsl:with-param name="sourcefile" select="$sourcefile"/>
    </xsl:apply-templates>
  </xsl:template>

I've also added comparable <xsl:param> and <xsl:with-param> declarations
throughout the example.  This is, I think, what you recommended.

The problem I face now is putting my changes into the production system,
which is processing a schema defined in about 90 XSD files.  I get how
to change the template definitions that exist already (assuming I'm
correct above), but I've also made the once-implicit xsd:schema
declaration explicit.  Is the implicit xsd:schema definition as simple
as I have it above, or is there more to it?  How should I have found
this out besides asking here?

Many thanks,

 -tom


Michael Kay <mike@xxxxxxxxxxxx> wrote:

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


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