RE: An issue with XPath 2.0 sequences (Was Re: RE: Mue

> 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