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
>