Subject: RE: [xsl] xsltproc and stringparam, changed behavior From: "Michael Kay" <mike@xxxxxxxxxxxx> Date: Fri, 19 Sep 2008 16:01:18 +0100 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] xsltproc and stringparam,, David Carlisle | Thread | Re: [xsl] xsltproc and stringparam,, tom sgouros |
Re: [xsl] xsltproc and stringparam,, David Carlisle | Date | [xsl] error in xsl:key, Vladimir Nesterovsky |
Month |