RE: Abbreviated Syntax "//"

I think you are suggesting that "//" as a free-standing expression should
mean the same as "/descendant-or-self::node()", that is, it should select
all the nodes in a document except attributes and namespaces.

If you can explain what use-cases require this construct, your argument
might be a little more convincing. At present you can do this using either
of the expressions "/descendant-or-self::node()" or "/|//node()", and I
can't say that those are expressions I see being used so often than a
shorter syntax for them is needed.

There definitely are parsing difficulties using "//" as both an operator and
an expression, just as there are with "/"; for example the expression "/ or
-1" is a well-known ambiguity in the XPath 1.0 grammar, and extending the
meaning of "//" would certainly exacerbate this. 

Michael Kay

> -----Original Message-----
> From: Emerson [mailto:emerson@harvestman.net] 
> Sent: 16 September 2003 17:05
> To: 'Kay, Michael'; public-qt-comments@w3.org
> Subject: 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 
> 
>