Re: [xsl] xslt 1.0 vs xslt 2.0 problem

Subject: Re: [xsl] xslt 1.0 vs xslt 2.0 problem
From: mark bordelon <markcbordelon@xxxxxxxxx>
Date: Wed, 3 Sep 2008 11:10:39 -0700 (PDT)
ALL,

All of you have given me some great information, as well as pointed out a sad and simple misunderstanding of mine regarding basic XSL. Firstly, I would like to thank all of you, and then apologize for wasting your time with what was actually such a simple issue. 

I hope to contribute as an answerer soon instead of only as a asker.

HAVE A GREAT DAY.


--- On Wed, 9/3/08, Andrew Welch <andrew.j.welch@xxxxxxxxx> wrote:

> From: Andrew Welch <andrew.j.welch@xxxxxxxxx>
> Subject: Re: [xsl] xslt 1.0 vs xslt 2.0 problem
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Date: Wednesday, September 3, 2008, 10:42 AM
> > What I am seeing is that this XSL only checks the FIRST
> child node's (B) attribute instead of checking all of
> them
> 
> XSLT 1.0 has a policy of never failing, so when you pass
> more than one
> item to something that only expects one, it will use the
> first and
> ignore the rest (this is sometimes called "First Item
> Semantics")
> 
> In this case you have:
> 
> //A[ contains(B/@a, "foo") ]
> 
> The element <A> has many <B> children, but the
> function contains() can
> only take a single node so the first is used and the
> discarded,
> effectively making your xpath:
> 
> //A[contains((B/@a[1]), 'foo')]
> 
> ...which you know is wrong because you want to check all
> the child nodes.
> 
> XSLT 2.0 reversed this concept and will fail early, giving
> you a nice
> error message instead of silently generating the wrong
> output.
> 
> 
> 
> -- 
> Andrew Welch
> http://andrewjwelch.com
> Kernow: http://kernowforsaxon.sf.net/

Current Thread