This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: An issue with XPath 2.0 sequences (Was Re: RE: Muenchian method, and keys 'n stuff)
- From: "Michael Kay" <michael dot h dot kay at ntlworld dot com>
- To: <xsl-list at lists dot mulberrytech dot com>
- Date: Fri, 1 Feb 2002 10:15:34 -0000
- Subject: RE: [xsl] An issue with XPath 2.0 sequences (Was Re: RE: Muenchian method, and keys 'n stuff)
- Reply-to: xsl-list at lists dot mulberrytech dot com
> I think the place where it breaks down most spectacularly is
> when it is
> combined with the apparent desire to model SQL NUL values as
> () using a
> list, even an empty one, as a value does not really combine
> with the non
> nested list model, which means that these "NUL" values vanish at
> interesting times and lead to strange anomalies in accumulation
> functions like sum() ...
Yes, I agree that there are cases where one would like to have () as an item
in a list. But I think any set of rules for "null" values leads to
anomalies, if the definition of an anomaly is "behavior that I wouldn't have
expected given my past experience of other systems".
Replicating the way SQL handles null turns out, I think, not to be feasible
in a model that is essentially hierarchic rather than tabular. Should
sum(day/@hours-worked) return null if there is a day for which the
@hours-worked attribute is absent? That would require a fundamental change
to the semantics of path expressions. Should sum(for $d in day return
$d/@hours-worked) be any different? You'll find people who will argue it
both ways, but neither way is free of "anomalies".
Mike Kay
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list