Re: [xsl] Saxon & xsltproc giving different output (SOLVED)

[Russell Urquhart <russurquhart1@xxxxxxxxxxx>]

I wanted to thank Michael for helping me on this.
(To recap, when i ran a given xslt on an xml data file, it was creating a table, based on a <modules_impacted> element where each row contained a bug impacting that given module, as it should. Running this xslt under xsltproc, was giving the table, with an extra row, containing a bug not related to the <modules_impacted> value of HDQ.

When i ran the same xslt under Saxon, I was not even getting the table at all.
I extracted out the template for responsible for creating the table.

In looking at this i started looking at the key dfined and used in the loop:

  <xsl:key name="module-index" match="errata_section" use="module_impacted"/>
and the containing loop:

     <xsl:for-each select="//errata_section[generate-id(.)=generate-id(key('module-index', module_impacted)[1])]">
        <xsl:sort select="module_impacted"/>


So i started looking in the data file for anomalies. Turns out that there was a <modules_impacted> element with a value of HDQ/1-wire. All the others had the value of HDQ. i.e.

<modules_impacted>HDQ/1-wire</modules_impacted>
<modules_impacted>HDQ</modules_impacted>
<modules_impacted>HDQ</modules_impacted>
<modules_impacted>HDQ</modules_impacted>
<modules_impacted>HDQ</modules_impacted>

Changing the first <modules_impacted> to have the value of HDQ, seemed to fix the problem under both processors. Both now seem to output the table with only the relevant bugs.

I'm glad its fixed, but can anyone share some light as to why such an anomaly would play out like that?

Thanks again.

Russ
On Sun, Dec 18, 2011 at 12:44:37AM +0000, Michael Kay wrote:
> There are several "messy" constructs that could be cleaned up. Try  
> cleaning them up and see if this makes the problem go away.