Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > XML > This XSLT problem makes no sense to me

Reply
Thread Tools

This XSLT problem makes no sense to me

 
 
Jean-François Michaud
Guest
Posts: n/a
 
      03-11-2008
Context:

I'm trying to compare XML tree fragments and I'm doing so by
outputting the attributes of each element in the tree and outputting
it to a string then normalizing the strings. Then I'm doing a contains
of the current string against the following-sibling::* to determine if
we have duplicates. If we have a duplicate, we move to the next item,
if there is no duplicate, we output the small tree.

I'm hitting a completely ridiculous problem that I can't wrap my head
around. I spend easily 2 hours trying to understand why this happened
yesterday and I'm about to punch the computer. When I output a string
that's not directly tied to the logic (or at least apparently not tied
to the logic), the logic works. When I remove the string output, the
logic stops working. Argh!

Here's the XSLT snippet

<xsl:template match="item-wrapper" mode="string">

<xsl:variable name="current">
<xsl:apply-templates mode="string" />
</xsl:variable>

<xsl:variable name="rest">
<xsl:apply-templates select="following-sibling::*"
mode="string" />
</xsl:variable>

<xsl:variable name="current-normalized">
<xsl:value-of select="normalize-space($current)" />
</xsl:variable>

<xsl:variable name="rest-normalized">
<xsl:value-of select="normalize-space($rest)" />
</xsl:variable>

<!-- <fix/> What the hell? -->
<!-- <xsl:value-of select="$current-normalized"/>-->

<xsl:choose>
<xsl:when test="contains($rest-normalized, $current-
normalized)">
<duplicate/>
</xsl:when>
<xsltherwise>
<noproblem/>
</xsltherwise>
</xsl:choose>
</xsl:template>

When <xsl:value-of select="$current-normalized"/> is not commented
out, I get the string representation of the XML tree in a normalized
form in the output for each item and the correct <duplicate/> and
<noproblem/> get outputted in the correct location after the
normalized strings. When I comment out the <xsl:value-of
select="$current-normalized"/>, the normalized current string, as
expected, stops being outputted, but all my outputs are <noproblem/>.
What the hell? What am I missing here?

Regards
Jean-Francois Michaud
 
Reply With Quote
 
 
 
 
Joseph Kesselman
Guest
Posts: n/a
 
      03-11-2008
Hard to be certain without seeing a full runnable copy, but this sounds
more like a bug in your XSLT processor than an expected behavior of XSLT.

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden
 
Reply With Quote
 
 
 
 
Martin Honnen
Guest
Posts: n/a
 
      03-11-2008
Jean-François Michaud wrote:

> When <xsl:value-of select="$current-normalized"/> is not commented
> out, I get the string representation of the XML tree in a normalized
> form in the output for each item and the correct <duplicate/> and
> <noproblem/> get outputted in the correct location after the
> normalized strings. When I comment out the <xsl:value-of
> select="$current-normalized"/>, the normalized current string, as
> expected, stops being outputted, but all my outputs are <noproblem/>.
> What the hell? What am I missing here?


I am not sure what the problem is, I would first try a second XSLT
processor to see if the problem is processor specific or not, if not
then there is certainly a problem with your code.
Try to isolate the problem and post a minimal but complete XML document
and stylesheet that allows us to reproduce the problem.


--

Martin Honnen
http://JavaScript.FAQTs.com/
 
Reply With Quote
 
Jean-François Michaud
Guest
Posts: n/a
 
      03-11-2008
On Mar 11, 10:24 am, Joseph Kesselman <(E-Mail Removed)>
wrote:
> Hard to be certain without seeing a full runnable copy, but this sounds
> more like a bug in your XSLT processor than an expected behavior of XSLT.
>
> --
> Joe Kesselman / Beware the fury of a patient man. -- John Dryden


Thanks much. I thought I was going insane . I tried with SaxonB9
and I get the same behavior. I'd have to try with Xalan, but I'd have
to modify the code a bit because Xalan doesn't behave exactly the same
way Saxon8/B9 does.

Regards
Jean-Francois Michaud
 
Reply With Quote
 
Jean-François Michaud
Guest
Posts: n/a
 
      03-11-2008
On Mar 11, 10:31 am, Martin Honnen <(E-Mail Removed)> wrote:
> Jean-François Michaud wrote:
> > When <xsl:value-of select="$current-normalized"/> is not commented
> > out, I get the string representation of the XML tree in a normalized
> > form in the output for each item and the correct <duplicate/> and
> > <noproblem/> get outputted in the correct location after the
> > normalized strings. When I comment out the <xsl:value-of
> > select="$current-normalized"/>, the normalized current string, as
> > expected, stops being outputted, but all my outputs are <noproblem/>.
> > What the hell? What am I missing here?

>
> I am not sure what the problem is, I would first try a second XSLT
> processor to see if the problem is processor specific or not, if not
> then there is certainly a problem with your code.
> Try to isolate the problem and post a minimal but complete XML document
> and stylesheet that allows us to reproduce the problem.
>
> --
>
> Martin Honnen
> http://JavaScript.FAQTs.com/


Ya tried SaxonB9. Same behavior. I'd have to try with Xalan but I'd
first have to modify the code so that it behaves the same way because
Xalan doesn't behave exactly like Saxon. I'm getting other odd
behaviors around this piece of code (Saxon) that are definitely not
expectable XSLT behavior. It looks like Saxon is not able to resolve
the strings correctly at runtime in this particular case.

I have to make this work so I'll just implement something else I have
in mind that's more painful to implement but less likely to fail.

If I get a second. I'll try to create a reduced set. I didn't want to
post a lot of code on the newsgroup uselessly.

Regards
Jean-Francois Michaud
 
Reply With Quote
 
Martin Honnen
Guest
Posts: n/a
 
      03-11-2008
Jean-François Michaud wrote:
> On Mar 11, 10:31 am, Martin Honnen <(E-Mail Removed)> wrote:
>> Jean-François Michaud wrote:
>>> When <xsl:value-of select="$current-normalized"/> is not commented
>>> out, I get the string representation of the XML tree in a normalized
>>> form in the output for each item and the correct <duplicate/> and
>>> <noproblem/> get outputted in the correct location after the
>>> normalized strings. When I comment out the <xsl:value-of
>>> select="$current-normalized"/>, the normalized current string, as
>>> expected, stops being outputted, but all my outputs are <noproblem/>.
>>> What the hell? What am I missing here?

>> I am not sure what the problem is, I would first try a second XSLT
>> processor to see if the problem is processor specific or not, if not
>> then there is certainly a problem with your code.
>> Try to isolate the problem and post a minimal but complete XML document
>> and stylesheet that allows us to reproduce the problem.
>>
>> --
>>
>> Martin Honnen
>> http://JavaScript.FAQTs.com/

>
> Ya tried SaxonB9. Same behavior. I'd have to try with Xalan but I'd
> first have to modify the code so that it behaves the same way because
> Xalan doesn't behave exactly like Saxon.


If you are using XSLT 2.0 then I would not try to change the stylesheet
for Xalan to compare Saxon 9 and Xalan, I would rather try another XSLT
2.0 processor like Gestalt <URL:http://gestalt.sourceforge.net/> or like
AltovaXML <URL:http://www.altova.com/altovaxml.html>


--

Martin Honnen
http://JavaScript.FAQTs.com/
 
Reply With Quote
 
Joseph Kesselman
Guest
Posts: n/a
 
      03-11-2008
I should have said: ... Or a bug in your data model.

Can you reduce the problem to a stand-alone stylesheet of just a few
lines? Does the problem occur when you just run it from a stylesheet and
an input document using a stand-alone XSLT processor?

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden
 
Reply With Quote
 
Jean-François Michaud
Guest
Posts: n/a
 
      03-11-2008
On Mar 11, 11:49 am, Joseph Kesselman <(E-Mail Removed)>
wrote:
> I should have said: ... Or a bug in your data model.
>
> Can you reduce the problem to a stand-alone stylesheet of just a few
> lines? Does the problem occur when you just run it from a stylesheet and
> an input document using a stand-alone XSLT processor?
>
> --
> Joe Kesselman / Beware the fury of a patient man. -- John Dryden


Both the stylesheet and the parser are standalone. I'm rolling the
testing through a .bat script and the saxon8.jar via command line.

I reduced the problem to the snippet I sent out. The stylesheet is
*much* larger. I'd have to spend some time to try and reduce the
example further and reproduce the problem on a reduced set. I'm
actually starting to think it might have to do with node-set
limitations.

I tried implementing the same end result through a different path I
had in mind; through string manipulation (string reduction) instead of
XML tree comparison via string comparison and I'm hitting a really
stupid out-of-scope limitation when I'm referencing an out of sequence
element (through a <xsl:for-each select="//whatever">). I'm unable to
reference values contained in the node-set inside the for-each
statement, and that, even if I drop the values from the node-set in a
variable prior to the for-each statement (referencing the variable
inside the for-each). The variable is always empty.

I can reference a variable, even if I'm out of sequence in the left
hand XML tree, only if I'm not playing with node-set values. This
parser is seriously starting to **** me off.

Regards
Jean-Francois Michaud
 
Reply With Quote
 
David Carlisle
Guest
Posts: n/a
 
      03-11-2008
Jean-François Michaud wrote:
> Context:
>
> I'm trying to compare XML tree fragments and I'm doing so by
> outputting the attributes of each element in the tree and outputting
> it to a string then normalizing the strings. Then I'm doing a contains
> of the current string against the following-sibling::* to determine if
> we have duplicates. If we have a duplicate, we move to the next item,
> if there is no duplicate, we output the small tree.
>
> I'm hitting a completely ridiculous problem that I can't wrap my head
> around. I spend easily 2 hours trying to understand why this happened
> yesterday and I'm about to punch the computer. When I output a string
> that's not directly tied to the logic (or at least apparently not tied
> to the logic), the logic works. When I remove the string output, the
> logic stops working. Argh!
>
> Here's the XSLT snippet
>
> <xsl:template match="item-wrapper" mode="string">
>
> <xsl:variable name="current">
> <xsl:apply-templates mode="string" />
> </xsl:variable>
>
> <xsl:variable name="rest">
> <xsl:apply-templates select="following-sibling::*"
> mode="string" />
> </xsl:variable>
>
> <xsl:variable name="current-normalized">
> <xsl:value-of select="normalize-space($current)" />
> </xsl:variable>
>
> <xsl:variable name="rest-normalized">
> <xsl:value-of select="normalize-space($rest)" />
> </xsl:variable>
>
> <!-- <fix/> What the hell? -->
> <!-- <xsl:value-of select="$current-normalized"/>-->
>
> <xsl:choose>
> <xsl:when test="contains($rest-normalized, $current-
> normalized)">
> <duplicate/>
> </xsl:when>
> <xsltherwise>
> <noproblem/>
> </xsltherwise>
> </xsl:choose>
> </xsl:template>
>
> When <xsl:value-of select="$current-normalized"/> is not commented
> out, I get the string representation of the XML tree in a normalized
> form in the output for each item and the correct <duplicate/> and
> <noproblem/> get outputted in the correct location after the
> normalized strings. When I comment out the <xsl:value-of
> select="$current-normalized"/>, the normalized current string, as
> expected, stops being outputted, but all my outputs are <noproblem/>.
> What the hell? What am I missing here?
>
> Regards
> Jean-Francois Michaud


without seeing full input and code it's hard to really tell, but the
behaviour seems expected to me.
with the code as it is (with the value-of commented out) the template
never puts any text into the result tree, just empty elements
<duplicate/> or <noproblem/> so if this template is typical, then
<xsl:variable name="rest">
<xsl:apply-templates select="following-sibling::*" mode="string"/>
</xsl:variable>

will just produce a sequence of empty elements, so the string value will
be "" so

<xsl:when test="contains($rest-normalized, $current-normalized)">

is testing if "" contains as a substring the normalised string value of
the current node, which will presumably test as false so you get
<noproblem/> every time.

As you are using saxon9 (thus xslt2) you probably want to be looking as
xsl:for-each-group to do duplicate removal, which is likely to be much
more efficient.

David



--
http://dpcarlisle.blogspot.com
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      03-11-2008
In article <(E-Mail Removed)>,
Jean-François Michaud <(E-Mail Removed)> wrote:

>When I output a string
>that's not directly tied to the logic (or at least apparently not tied
>to the logic), the logic works. When I remove the string output, the
>logic stops working. Argh!


Look carefully:

> <xsl:template match="item-wrapper" mode="string">
>
> <xsl:variable name="current">
> <xsl:apply-templates mode="string" />
> </xsl:variable>


$current is set to the result of applying the string-mode templates to
the children of the current node. And this *is* the string-mode template.
So when you comment out this:

><!-- <xsl:value-of select="$current-normalized"/>-->


you are changing $current!

-- Richard
--
:wq
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Why declaring a private abstract method makes no sense?? Neroku Java 6 02-08-2007 04:13 PM
Do u think this makes sense?? Developer.Man4@gmail.com ASP .Net 3 12-12-2006 02:41 PM
Sending number - it makes no sense! logiclips@yahoo.com Java 11 09-26-2006 05:49 PM
unit testing failure makes no sense listservs@mac.com Python 1 08-30-2006 10:13 PM
when GOTO makes sense. Debashish Chakravarty C Programming 45 12-09-2003 07:12 PM



Advertisments