RE: xpath2 functions returning ()

> > Xpath 2 seems to want to treat () special in many contexts. Most of
> > which seem unfortunate:-)

Most of this came from a desire to do something akin to null values in SQL.
In fact, until quite a late stage before publication, XPath 2.0 had SQL-like
3-valued-logic, so that if @a was an absent attribute, @a = 3 and not(@a =
3) would both return "null" (represented as (), the empty sequence), which
would be treated in a predicate as false. 3-valued logic has gone from the
current draft, but there's still a general rule that operators and function
which get () as one of their arguments produce () as the result, unless
something else makes sense.

> > The example above is one, sum() returning
> > the empty sequence instead of 0 is another (that seems to be much
> > worse, and will mean that you will almost always have to special
> > case any value returned from sum() to check if it is empty and if so
> > replace it with 0)

This is flagged in the draft as an open issue (I personally regard it as a
bug, but not everyone agrees). It got in there because people wanted it to
behave the same way as in SQL: apparently in SQL the sum of an empty set is
null. Why SQL defines it that way is anyone's guess.

I think the general principle of using () for a non-value is OK, despite the
problem that it can't exist as an item within a sequence; we just need to
look in more detail at the cases where it causes compatibility problems.
Some of these have already been fixed, for example () is now treated as ""
when used as an argument to concat().

Mike Kay


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