On 8 Mar 2019, at 08:44, Dave Pawson dave(_dot_)pawson(_at_)gmail(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
On Fri, 8 Mar 2019 at 08:40, Michael Kay mike(_at_)saxonica(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Because if $a is an empty sequence (which is the situation on the first
call), then $a[last()] is an empty sequence, and ($x + ()) returns an empty
sequence, not $x.
I'm sure I'm not the only one thinking that sounds illogical Mike? (DC?)
I'd appreciated the 'logic' behind that decision (maths?)
The design intent was that () should have similar behaviour to null in SQL; in
SQL (simplifying greatly), any operation that has null as an operand produces
null as a result. The idea is that if you do a query
//customer[location = 'UK']
then a customer whose location is absent (null) does not get selected; you
don't have to treat an absent location as some kind of exception condition.
Similarly //customer[abs(amount-outstanding) > 10000] selects nothing if
amount-outstanding is absent/null, because abs(()) is ().
There's one significant difference between the way SQL does it and the way
XPath does it; SQL has full three-valued logic in which not(null) is null,
whereas in XPath, not(()) is true.
It's all about making it convenient to handle datasets in which some of the
values are not always present.
There is of course a logic behind this, but it's not the classical two-valued
logic that they teach in elementary school.
Michael Kay
Saxonica
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--