- From: David Carlisle <davidc@nag.co.uk>
- Date: Fri, 4 Jan 2002 17:37:36 GMT
- To: xsl-list@lists.mulberrytech.com
- CC: www-xpath-comments@w3.org
Mike Kay (on xsl-list) > Most of this came from a desire to do something akin to null values in > SQL. Yes, but null makes sense in a table model as you've got to put something there, but an XML query language shouldn't be making assumptions about how data is encoded in the XML. I may want to mark missing or unknown data with an attribute or a different element or any number of possible encodings, so the query language should make the minimum possible assumptions about the relevance of a sequence being empty. The Xpath 1.0 behaviour of coercing empty node sets to false was good and useful (as in lisp) but this seems to be severely compromised in xpath 2. > This [sum()] is flagged in the draft as an open issue Saying that perhaps sum(/..) should return 0 rather than () for compatibility reasons suggests that somehow one would want () but that 0 is being forced by the past, but I can't see how this can ever be useful, if the stylesheet author wants to special case an empty node set want to special case the empty sequence (s)he can always do that before calling sum(). the situation with min or max is rather different as an empty set doesn't have a maximum value, so here you might want to return () as essentially an error flag. (Alternative would be to return the infinte float value, except that probably doesn't type check in general, or an error) David _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
Received on Friday, 4 January 2002 12:37:57 UTC