The problem is here:
<xsl:variable name="unique-rows" select="//[EMAIL
PROTECTED]'ID'][not(.=preceding::field)]"/>
the preceding axis is grabbing all preceding nodes named field, including
/page/include/import/field which has a value of 0003. This is matched with the field
named ID that has a value of 0003 and so the expected field is not included in the
unique-rows variable.
This fixes the problem:
<xsl:variable name="unique-rows" select="//[EMAIL
PROTECTED]'ID'][not(.=preceding::[EMAIL PROTECTED]'ID'])]"/>
I'm not that good at recognizing XSL errors by sight yet so I use a general debugging
process to help find these types of errors, usually fairly quickly. First, start by
limiting the input xml as much as possible, just enough to reproduce the error. In
this case I just stripped everything after the offending node, re-ran and noted that
the error still occurred; the element was still missing. Now I can add debugging nodes
to the output without being overwhelmed with a large volume of irrelevant output.
Next I started adding <xsl:copy-of> elements to the base template (match="/") to dump
nodes that I was interested in.
To start I looked at the nodes selected for the unique-rows variable
<unique-rows><xsl:copy-of select="//[EMAIL
PROTECTED]'ID'][not(.=preceding::field)]"/></unique-rows>
The output gave a clue where to start looking, note the missing 0003:
<unique-rows>
<field name="ID">0000</field>
<field name="ID">0001</field>
<field name="ID">0002</field>
<field name="ID">0004</field>
<field name="ID">0005</field>
</unique-rows>
To figure out why 0003 was not getting included I changed the copy-of into a for-each
and iterated over all of the selected field elements and dumped pieces of the original
xpath:
<unique-rows>
<xsl:for-each select="//[EMAIL PROTECTED]'ID']">
<the-field><xsl:copy-of select="."/>
<preceding><xsl:copy-of select="preceding::field"/></preceding>
<include-it><xsl:value-of
select="not(.=preceding::field)"/></include-it>
</the-field>
</xsl:for-each>
</unique-rows>
The output gave the answer:
<the-field>
<field name="ID">0000</field>
<preceding>
<field name="OTYP">0003</field>
<field name="TYPE"/>
<field name="CODE"/>
<field name="MESSAGE"/>
<field name="LOG_NO"/>
<field name="LOG_MSG_NO">000000</field>
<field name="MESSAGE_V1"/>
<field name="MESSAGE_V2"/>
<field name="MESSAGE_V3"/>
<field name="MESSAGE_V4"/>
<field name="MANDT"/>
</preceding>
<include-it>true</include-it>
</the-field>
<the-field>
<field name="ID">0000</field>
<preceding>
<field name="OTYP">0003</field>
<field name="TYPE"/>
<field name="CODE"/>
<field name="MESSAGE"/>
<field name="LOG_NO"/>
<field name="LOG_MSG_NO">000000</field>
<field name="MESSAGE_V1"/>
<field name="MESSAGE_V2"/>
<field name="MESSAGE_V3"/>
<field name="MESSAGE_V4"/>
<field name="MANDT"/>
<field name="ID">0000</field>
<field name="PARAM">KEY</field>
<field name="VALUE">AA</field>
<field name="MANDT"/>
</preceding>
<include-it>false</include-it>
</the-field>
... snip ...
When it got to <field name="ID">0003</field> the include-it element was false for the
first and second instance of the element so I looked at the output in the <preceding>
element and noticed that the field named OTYP had a value of 0003. Since the point of
the xpath is to compare with other fields named ID I added the predicate expression to
include only field elements with a name attribute ID.
Hope this helps,
Josh
-----Original Message-----
From: Michael Gerzabek [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 2:59 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: XSL question (was: XSL question in Cocoon)
Indeed that would be the right place, thanks.
Anyway since I use Cocoon with Xalan as XSLT Processor I'm not
sure where the problem belongs to. So I'll have a second run now
with results enclosed.
I've an input xml [1] that gets transformed with an xsl [2] and I think
the result should look like [3]. But whatever I do, the result looks
like [4].
[1] xml.xml
[2] xsl.xsl
[3] right.xml
[4] wrong.xml
I've tested this on Cocoon and on Eclipse 3.0M4 and get consistently
the same results :( Needless to say both use Xalan.
BTW: The difference is the row node with id="4" which is missing
in [4].
Any ideas?
Regards,
Michael
--
Michael, it's hard to say what's wrong without knowing what you expect.
What do you mean by "unique"? Having the same content? Having the same
@name? I think your unique-rows variable may not contain what you think.
BTW, the best place to go with xsl queries is usually the MulberryTech XSL
list, rather than the Cocoon lists.
Con
-----Original Message-----
From: Michael Gerzabek [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 2 December 2003 08:51
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: XSL question in Cocoon
sorry for crossposting, but I'm not a hundred percent sure
where to go with this issue.
I run C21 with a pretty FileGenerator that gives me xml.xml [1] attached
right on. As next step in my pipeline I use TraxTransformer(xalan, no XSLTC)
with xsl.xsl [2] to make some other xml out of it. Then I serialize
everything with
XMLSerializer.
I do this quite often with different sources and the same stylesheet. And it
works
fine. But with the data enclosed I miss the third node in output and I can't
after a
hundred looks say why!?
Does anyone know why or where to direct my question?
Thanks in advance
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
