RE: Abbreviated Syntax "//"

Michael, 


I know that the current interpretation of "//" has been around since
Xpath 1.0, but what im suggesting is actually not that much of a
departure from the concepts and patterns that Xpath uses elsewhere.

For example, using the abreviated parent syntax is it not possible to
say:

"child::node()/child::node()/.."

And 

"child::node()/../child::()"

I see no difference between ".." and "//".  The key to understanding
this suggestion in my opinion is to see that "//" translates
syntactically to "/X" or "/X/" depending on whether it is followed by
another step.  Expansion is an abstract creation of the free mind, and
does not actually become part of the synatx of the expression. To say
that "//para" expands to "/descendant-or-self::node()para" is
meaningless when processing the Xpath statement, because like "..", "//"
is an abreviation - and therefore both a separator and a step.

I would liken the problem to that of a URL, where sometimes there is a
trailing "/"  i.e. "http://harvestman.net/" and othertimes there is not
"http://harvestman.net".  But to a suitably equipped URL/URI parser, the
distinction is irrelevant, because the trailing slash "/" serves no
purpose unless there is a following path.  

I belive that Xpath should behave the same way, that is... to make the
distinction between the separator "/" and the step. 


[36]    PathExpr    		::=	("/" RelativePathExpr?)
						| ("//"
RelativePathExpr)
						| RelativePathExpr

[37]    RelativePathExpr	::=	StepExpr (("/" | "//")
StepExpr)* 


Nowhere in the above Xpath grammar can "//" be followed by a "/" so I
can not see how you could ever end up with an expression of "///"


All that is required is to modify the production of [36] to become:

[36]    PathExpr    		::=	(("/" | "//") RelativePathExpr?)
						| RelativePathExpr

Similaryly production [37] to 

[37]    RelativePathExpr	::=	StepExpr ( "//" | (("/" | "//")
StepExpr))*

Or less pedandically if your not concerned about trailing "/"

[37]    RelativePathExpr	::=	StepExpr (("/" | "//")
StepExpr?)*

I would debate just how infrequently the expressions you showed are
used, expecially since "//" abreviates one of the most common and
syntactically long location steps.  I personally use "//" all the time,
though I can understand that many users may steer away from the
overhead, suffice to say that my implementation provides optimisations
such that using "//" does not incur the cost of selecting all descendant
nodes in a document.

emerson

-----Original Message-----
From: Kay, Michael [mailto:Michael.Kay@softwareag.com] 
Sent: Tuesday, 16 September 2003 4:22 PM
To: emerson@harvestman.net; public-qt-comments@w3.org
Subject: RE: Abbreviated Syntax "//"


If "//" expanded to "/descendant-or-self::node()" then "//para" would
expand to "/descendant-or-self::node()para", which would be a syntax
error.

The language could of course be defined so that "//" was a valid
expression, meaning perhaps //* or //node() or even /|//node(), but
since all these possible interpretations can already be easily written,
there seems little benefit in abbreviating them further, especially as
none of these expressions seem to be frequently required in practice.

Also, if "//" was a valid expression, then it could be followed by the
"/" operator, exacerbating further the problems in parsing pathological
expressions such as "///".
Michael Kay 

> -----Original Message----- 
> From: Emerson [mailto:emerson@harvestman.net] 
> Sent: 16 September 2003 03:11 
> To: public-qt-comments@w3.org 
> Subject: Abbreviated Syntax "//" 
> 
> 
> 
> 
> Ive just noticed something that hasn't bothered me in the 
> past due mainly to an omission on my part.  In implementing 
> some Xpath 2.0 features into my now hybrid 1.0 processor I 
> noticed that according to both specifications; 
> 
http://www.w3.org/TR/xpath20/#abbrev 
The abreviated, location path in 1.0 speak, or path expression in 2.0
language  i.e. "//" Is actually interpreted as
"/descendant-or-self::node()/" rather than "/descendant-or-self::node()"
I beg to ask, why the trailing slash "/" ?  
This forces the abreviated syntax to have a following step, when there
is a perfectly valid reason for wanting to use "//" alone.
I don't like to deviate, but this is one part of the grammar that I
don't think I will be enforcing... 
emerson

Received on Tuesday, 16 September 2003 12:05:15 UTC