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