Re: Implementing the Grammar

Ingo Macherius wrote:

> 1. Tokenizing
> 
> The killer sentence in XPath is
> "If there is a preceding token and the preceding token is not one of @, ::, (, [, , or an {HYPERLINK  \l "NT-Operator"}Operator,
> then a * must be recognized as a {HYPERLINK  \l "NT-MultiplyOperator"}MultiplyOperator and an {HYPERLINK "http://www.w3.org/TR/REC-xml-names" \l "NT-NCName"}NCName must be recognized as an
> {HYPERLINK  \l "NT-OperatorName"}OperatorName."
> 
> Couldn't this be expressed in a positive formulation ? The way it is it's complicated and does not
> fit naturally in the rest of the grammar. Note that "Operator" depends on the tokens from
> "OperatorName".

I agree it's complicated, but I haven't found any simpler way to express
it.

> 2. AbbreviatedAxisSpecifier (production [13])
> 
> This is a killer because it can evaluate to an empty string. As via [5]->[4] is can start a Step
> production. Couldn't [13] be simply merged with [6], e.g. by moving the "::" token from [6] to [5] ?

What's hard about this?  Just do something like:

step:
  axis node_test predicates
  | DOT
  | DOT_DOT
  ;

axis:
  /* empty */
  | AXIS_NAME COLON_COLON
  | AT
  ;

For explanatory reasons I want to keep the productions that describe
abbreviations separate.

> 3. Grouping
> 
> Is it correct that
>         /a/(a|b)
> is not a legal XPath production but must be written
>         /a/a | /a/b
> ?

Yes.

> If so, is this intended ?

Yes.

> I am a bit envolved with XQL, so I wondered why this is that clumsy in
> Xpath (probably thó keep things simple).

Yes.  I expect a future version of XPath will lift the restriction, but
exactly how is not yet clear.

James

Received on Sunday, 29 August 1999 23:32:11 UTC