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

Michael,

what should we understand from this example ? That you would like
to extend the proposal to the left hand side of the "/" ? Or just
do not accept the proposal ?

Best regards
Dana




On Feb 14, 2004, at 11:11 AM, Michael Kay wrote:

> Another observation on this proposal.
>  
> It will allow me to get the string value of a node by writing
>  
> chapter/heading/string()
>  
> It will allow me to tokenize the value of a node by writing
>  
> chapter/heading/tokenize(., "\W+")
>  
> So I might expect that if I want to tokenize the string value of a  
> node, I can write:
>  
> chapter/heading/string()/tokenize(., "\W+")
>  
> But I can't! I now need to write the expression using a completely  
> different style, for example
>  
> chapter/heading/tokenize(string(), "\W+")
>  
> Michael Kay
>  
>  
> -----Original Message-----
> From:public-qt-comments-request@w3.org  
> [mailto:public-qt-comments-request@w3.org]On Behalf Of Don Chamberlin
> Sent: 11 February 2004 23:51
> To:public-qt-comments@w3.org
> Subject:[XQuery] IBM-XQ-007: Last step in a path expression
>
>
> (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