Re: [xsl] XSLT 2.0 courses?

["David Carlisle d.p.carlisle@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

On Mon, 21 Sep 2020 at 11:53, Michael Kay mike@xxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Well, I thought about using EBV, so it means (if ($a) then $a else $b),
> but zero is falsey, so you get surprises with, for example
>
> @price * (1 + (@VAT_Rate otherwise 0.2))
>
> which potentially gives the wrong answer if @VAT_Rate is present but zero.
> And it also gets complicated with atomization: if the attribute is present
> but set to a zero length string, which way do you go?
>
> Michael Kay
> Saxonica
>
>
Just to give a slightly dissenting voice....

The trouble with any such definition  especially given the "interesting"
details around EBV and emptiness, is that it ends up being like != which
looks like a useful syntactic shorthand but is actually a massive trap for
the unwary.

$a zzz $b

meaning more or less $a  unless it's empty (or has false Effective boolean
value or ...) else $b  will never be clear to anyone who hasn't read every
line of the spec, even if it _looks_ clear, and that isn't clearly an
advantage over

($a,$b[empty($a)])

or

or (if $a and $b have length at most one, like the VAT example)

($a,$b)[1]

or for the EBV version, as you said

(if($a) then $a else $b)

These may all look "less readable" to the man in the street not used to
reading xpath, but such people don't need to read this anyway. I'd say they
are all more readable to anyone used to xpath at all, especially the common
($a,$b)[1] idiom where that is applicable.

David







> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/2739265> (by
> email <>)