Subject: RE: [xsl] An issue with XPath 2.0 sequences (Was Re: RE: Muenchian method, and keys 'n stuff) From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx> Date: Fri, 1 Feb 2002 10:15:34 -0000 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] An issue with XPath 2.0 s, David Carlisle | Thread | Re: [xsl] An issue with XPath 2.0 s, David Carlisle |
RE: [xsl] Choosing different output, Andrew Welch | Date | RE: [xsl] basic question about xpat, Michael Kay |
Month |