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>
--~--