[xsl] RE: XSL question (was: XSL question in Cocoon)

["Josh Canfield" <josh.canfield@xxxxxxxxxxxx>]

The problem is here:

  <xsl:variable name="unique-rows" select="//field[@name='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="//field[@name='ID'][not(.=preceding::field[@name='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="//field[@name='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="//field[@name='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:michael.gerzabek@xxxxxxxxx]
Sent: Wednesday, December 03, 2003 2:59 AM
To: XSL-List@xxxxxxxxxxxxxxxxxxxxxx; xalan-j-users@xxxxxxxxxxxxxx;
users@xxxxxxxxxxxxxxxxx
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:michael.gerzabek@xxxxxxxxx]
Sent: Tuesday, 2 December 2003 08:51
To: users@xxxxxxxxxxxxxxxxx; xalan-j-users@xxxxxxxxxxxxxx
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



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list