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 17:45:48 UTC