RE: [XQuery] 3.2 Path expressions returning non-nodes

This definition could work, I think, but I still feel more comfortable
with a separate operator. A separate operator would allow:

(a) atomic values on the lhs

(b) nodes on both sides, without sorting into doc order

(c) heterogeneous sequences on either side

which seems much cleaner.

The main benefit of overloading "/" to allow atoms on the right (which,
incidentally, has previously been suggested by Don Chamberlin) is
probably that people can use it without thinking about the differences,
but I'm not sure we should encourage coding without thinking!

Michael Kay


> -----Original Message-----
> From: Sarah Wilkin [mailto:swilkin@apple.com] 
> Sent: 04 February 2004 18:28
> To: Michael Kay
> Cc: public-qt-comments@w3.org
> Subject: Re: [XQuery] 3.2 Path expressions returning non-nodes
> 
> 
> I see what you mean. However, I don't want the proposed 
> solution to get 
> in the way of the problem. Our new proposal:
> If each evaluation of E2 results in a sequences of nodes, they are 
> combined in document order, removing duplicates.
> If each evaluation of E2 results in a sequence of atomic 
> values of the 
> same type, they are returned in the order of the result from the 
> primary expression.
> Otherwise a type error is raised.
> 
> --Sarah
> 
> On Feb 3, 2004, at 3:24 PM, Michael Kay wrote:
> 
> >
> >> The rule seems simple:
> >> If the path ends with an AxisStep, proceed as usual (eliminate 
> >> duplicate nodes and return in sequence order) If the path 
> ends with a 
> >> FilterStep, order the sequence in the same order as the 
> result from 
> >> the primary expression.
> >
> > I think it's not generally a good idea for the semantics of an 
> > operator to depend on the syntactic form of its operands; it should 
> > depend only on their value and type. Otherwise you get a lack of 
> > composability: you can't safely replace an expression with 
> a function 
> > that evaluates that expression.
> >
> > It also means that A/B gives a different answer from A/(B).
> >
> > Michael Kay
> >
>

Received on Wednesday, 4 February 2004 14:16:22 UTC