xsl-list
[Top] [All Lists]

RE: [xsl] xsltproc and stringparam, changed behavior

2008-09-19 04:53:21
The xsd:include template invokes the xsd:simpleType template indirectly: in
between, the built-in template for xsd:schema is invoked.

In XSLT 1.0, built-in templates do not pass their parameters on to the
templates that they call. So the "new" version of xsltproc is implementing
the XSLT 1.0 specification correctly.

XSLT 2.0 changes this, so that built-in templates *do* pass their parameters
on - but only if the parameter is actually declared as a local parameter of
the called template (which in your case, it isn't). So the behaviour you are
seeing would also be correct for an XSLT 2.0 processor.

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