Woooooow. Thank you very very much!!
Michael
--
At 21:59 03.12.2003, you wrote:
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]
===============================================
Michael Gerzabek tel: +41 1 455 70 00
Swissrisk AG fax: +41 1 455 70 01
Räffelstrasse 32 mailto:[EMAIL PROTECTED]
8045 Zürich www.swissrisk.com
===============================================
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
