RE: Comments on XPointer 1.0 CR

I think this is thoroughly ugly. The "/" operator has a node-set on the left
and a step on the right. If we allow a function-call such as range() on the
right, the implication is that range() is returning a step. Functions return
a value, so this means that "step" becomes a new XPath data type. This is
not entirely unreasonable, I've seen a number of requests to have a variable
reference on the right of the "/" operator, so presumably it's sensible to
have a variable whose value is a step. In fact I think a step is really a
kind of function, and having functions as a data-type is a very powerful way
forward. But this all needs thinking through much more carefully.

What I'm saying is, you can't just overload the syntax with something that
looks sort-of-right on the surface without analysing the implications in
terms of the fundamentals of the language.

Mike Kay 

> -----Original Message-----
> From: Daniel Veillard [mailto:Daniel.Veillard@w3.org]
> Sent: 12 September 2000 22:45
> To: Kay Michael
> Cc: 'www-xml-linking-comments@w3.org'; w3c-xsl-wg@w3.org
> Subject: Re: Comments on XPointer 1.0 CR
> 
> 
> On Thu, Jun 08, 2000 at 02:56:46PM +0100, Kay Michael wrote:
> > 9. Section 5.4.1, Note. This extension to XPath syntax 
> needs much more
> > formal treatment. Exactly how is the BNF modified? Which 
> functions are
> > allowed after a "/"? What are the semantics? I'm worried 
> that this extension
> > is "jumping the gun" in terms of how XPath evolves. I think 
> that this kind
> > of requirement, along with many others, would be much 
> better met by allowing
> > a function to take an expression (or function) as an 
> argument, so it could
> > be written say range-to(id("chap1"), function: 
> following::REVEND(1]). (This
> > concept is needed to do things such as universal and existential
> > quantifiers, summing an arbitrary expression, etc).
> 
> --------------------------------------------
>   the change is a single addition to the production [3] of the XPath
> specification:
> 
>   [3]   RelativeLocationPath ::=   Step |
>                                    RelativeLocationPath '/' Step |
> 				   AbbreviatedRelativeLocationPath
> 
>  Basically this is a single exception for the range-to() function.
> It is not a generic change and not extendable to other functions.
> This is used to express that a range computation must be made for
> each of the nodes in the current nodelist. The Modified XPath
> production becomes:
> 
>   [3xptr] RelativeLocationPath ::=   Step |
>                                    RelativeLocationPath '/' Step |
> 				   AbbreviatedRelativeLocationPath |
>                                    'range-to(' 
> RelativeLocationPath ')'
> 
>   The range-to derivation of the [3xptr] prodution is not allowed 
> from a RelativeLocationPath itself the result of a range-to derivation
> of [3xptr].
> --------------------------------------------
> 
> This last rule could also be expressed using productions but would
> force regenerating a second set of descendant of RelativeLocationPath
> and use it into the new derivation of production [3xptr]. I doubt it
> would be more understandable.
> 
>   Changing the syntax at this point would probably force us again to
> do a Last Call review and would generate considerable delays. While
> not perfect this is still a workable solution and assuming that the
> explanations provided before are enclosed in the final version, do
> you think it is acceptable ?
> 
> Daniel
> 
> -- 
> Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes  | Today's Bookmarks :
> Tel : +33 476 615 257  | 655, avenue de l'Europe | Linux XML 
> libxml WWW
> Fax : +33 476 615 207  | 38330 Montbonnot FRANCE | Gnome 
> rpm2html rpmfind
>  http://www.w3.org/People/all#veillard%40w3.org  | RPM badminton Kaffe
>

Received on Tuesday, 12 September 2000 20:02:47 UTC