[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: xsltproc and stringparam, changed behavior
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|