- From: Ingo Macherius <macherius@darmstadt.gmd.de>
- Date: Tue, 17 Aug 1999 21:10:21 +0200
- To: www-xpath-comments@w3.org
Hello, this is a small report based on my experience translating the XPath EBNF Grammar into a JavaCC grammar. As far as I'm aware all other XSL parsers are handcoded, so this may be of interest. The grammar is working 90% after an afternoon of coding. I can send the grammar if you like to see it. First of all the grammar productions translated well, beside some left recursions but they were easy to remove. In sum there were three problems I found kind of hard: 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". 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] ? 3. Grouping Is it correct that /a/(a|b) is not a legal XPath production but must be written /a/a | /a/b ? If so, is this intended ? I am a bit envolved with XQL, so I wondered why this is that clumsy in Xpath (probably thó keep things simple). Thanks, ++im -- Ingo Macherius//Dolivostrasse 15//D-64293 Darmstadt//+49-6151-869-882 GMD-IPSI German National Research Center for Information Technology mailto:macherius@gmd.de http://www.darmstadt.gmd.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Zappa)
Received on Tuesday, 17 August 1999 14:58:41 UTC