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(_at_)as220(_dot_)org]
Sent: 19 September 2008 06:00
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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
--~-----------------------------------------------------------------
- XSL-List info and archive:
http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--
------------------------
tomfool at as220 dot org
http://sgouros.com
http://whatcheer.net
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--