[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: xsltproc and stringparam, changed behavior

Subject: Re: xsltproc and stringparam, changed behavior
From: tom sgouros <tomfool@xxxxxxxxx>
Date: Mon, 22 Sep 2008 17:20:25 -0400
Re:  xsltproc and stringparam
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:  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

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.