RE: [XQuery] IBM-XQ-007: Last step in a path expression

Further candidates for defaulting the argument to the context item are
node-name() and document-uri(), if we want consistency (which we do,
despite appearances!).
 
Michael Kay

-----Original Message-----
From: public-qt-comments-request@w3.org
[mailto:public-qt-comments-request@w3.org] On Behalf Of Don Chamberlin
Sent: 12 February 2004 22:26
To: Daniela Florescu
Cc: public-qt-comments@w3.org
Subject: Re: [XQuery] IBM-XQ-007: Last step in a path expression



Hi Dana, 
Thanks! Yes, I would support your proposal to make the context item the
default operand for data(), and I agree that this enhances the value of
the proposal to allow path expressions to return atomic values.
--Don Chamberlin




Daniela Florescu <danielaf@bea.com> 


02/12/2004 12:00 PM 


To
Don Chamberlin <chamberl@almaden.ibm.com> 

cc
public-qt-comments@w3.org 

Subject
Re: [XQuery] IBM-XQ-007: Last step in a path expression

	




I understand Don, thank you.

I totally agree with this version of the proposal.

However, please remark that the following expression
that most of my customers would like to write:

$x/a/b/data()

would still not be valid because data() needs  an explicit
argument. Can we also make the current node the implicit
argument for data() ( in case there is no argument) ?

Best regards,
Dana



On Feb 12, 2004, at 10:30 AM, Don Chamberlin wrote:

>
> Dana,
> All of your questions are answered in the proposal I cited, originally

> posted by Sarah Wilkin, which is very brief, clear and complete.  
> Please take the time to read it:
> http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/ 
> 0100.html
>
> To recapitulate, duplicate elimination and doc-order-sorting is  
> applied if the result is a sequence of nodes. If the result contains a

> mixture of nodes and atomic values, a type error is raised. If the  
> statically inferred type contains both nodes and values, and static  
> type checking is in effect, the type error is a static error. This is

> consistent with our handling of type errors for all other operators.
>
> Note that this proposal does not "overload" the "/" operator--it  
> simply eliminates the unnecessary and unmotivated restriction that  
> "each evaluation of E2 must result in a sequence of nodes, otherwise a

> type error is raised." Eliminating this restriction makes the "/"  
> operator more useful and does not conflict with any other part of the

> language.
>
> --Don Chamberlin
>
>
>
>
>
> Daniela Florescu <danielaf@bea.com>
>
> 02/11/2004 05:31 PM
>
> To
> Don Chamberlin <chamberl@almaden.ibm.com>
>
> cc
> public-qt-comments@w3.org
>
> Subject
> Re: [XQuery] IBM-XQ-007: Last step in a path expression
>
>
>
>
>
>
>
> Don,
>
> but in this new proposal, under which conditions would you apply  
> sorting
> by doc order  and duplicate elimination ?
>
> What if the dynamic answer contains a mixture of nodes and values?
>
> And what if the statically inferred type contains both nodes and  
> values  
> ?
> Don't you want to know at compile time if you have to do a sort or not

> ?
>
> I am not sure I understand the proposal as written.
>
> Best regards
> Dana
>
>
> On Feb 11, 2004, at 3:50 PM, Don Chamberlin wrote:
>
> >
> > (IBM-XQ-007) Section 3.2 (Path Expressions): The definition of a  
> path  
> > expression should be revised to remove the restriction that the  
> > expression on the right side of "/" must return a sequence of nodes.

>  
> > The restriction should be retained for the expression on the left  
> side  
> > of "/". In effect, this would permit the last step in a path to  
> return  
> > one or more atomic values. This feature has recently been requested

> by  
> > Sarah Wilkin  
> > (http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/
> > 0100.html) who proposes the following rule: When evaluating E1/E2,  
> if  
> > each evaluation of E2 returns a sequence of nodes, they are combined

>  
> > in document order, removing duplicates; if each evaluation of E2  
> > returns a sequence of atomic values, the sequences are concatenated

> in  
> > the order generated; otherwise a type error is raised. Like all type

>  
> > errors, this error can be raised either statically or dynamically,  
> > depending on the implementation. This rule provides well-defined  
> > static and dynamic semantics for path expressions.
> >
> > To illustrate the usability advantages of this proposal, consider a

> > document containing "employee" elements, each of which has child  
> > elements "dept", "salary", and "bonus". To find the largest total  
> pay  
> > (salary + bonus) of all the employees in the Toy department, here is

>  
> > what I think many users will write:
> >
> > max( //employee[dept = "Toy"]/(salary + bonus) )
> >
> > Unfortunately in our current language this is an error because the  
> > final step in the path does not return a sequence of nodes. The user

>  
> > is forced to write the following:
> >
> > max( for $e in //employee[dept = "Toy"] return ($e/salary +  
> $e/bonus) )
> >
> > This expression is complex and error-prone (users will forget the  
> > parentheses or will forget to use the bound variables inside the  
> > return clause). There is no reason why this query cannot be  
> expressed  
> > in a more straightforward way. Users will try to write it as a path

> > expression and will not understand why it fails.
> >
> > Another very common example is the use of data() to extract the  
> typed  
> > value from the last step in a path, as in this case:  
> >  //book[isbn="1234567"]/price/data().  This very reasonable  
> expression  
> > is also an error and the user is forced to write  
> > data(//book[isbn="1234567"]/price).
> >
> > Note that I am NOT asking for a general-purpose mapping operator,  
> > which I think is not in general needed since we already have a  
> > for-expression. Instead, I think we should simply relax the  
> unnatural  
> > and unnecessary restriction that is currently placed on path  
> > expressions. This will remove a frequent source of errors and will  
> > improve the usefulness of path expressions, without precluding us  
> from  
> > introducing a general-purpose mapping operator later if a consensus

> > emerges to do so.
> >
> > --Don Chamberlin
>