[
Lists Home |
Date Index |
Thread Index
]
* Petr Cimprich <petr@gingerall.cz> [2005-01-17 07:02]:
> Alan Gutierrez wrote:
> > Also off-list, Petr Cimprich suggests:
> >> I think we should try to define an EBNF grammar that could be
> >> implemented in different languages. Some time ago, Oliver Becker
> >> derived an STXPath grammar from XPath2. Here is the diff:
> >> http://www.informatik.hu-berlin.de/~obecker/stxpath/stxpath.html
> >> This approach seems to work, we can start again, take XPath2
> >> and discuss necessary constrains.
> > Here's XPath 2.0:
> >
> > http://www.w3.org/TR/xpath20/
> From my point of view, the first step should be to define a context
> available for XPattern evaluation. The context then determines which
> XPath grammar constructs make sense as well as their real meaning. Thus,
> the context should be agreed before the reduction of XPath grammar starts.
>
> The context can include e.g. these items:
> 1. The current node
> 2. All the ancestors of the current node
> While the 1. and 2. can be maintained at nearly no costs (and I can
> hardly imagine a pattern matching without them) the other points are
> trade-offs between the language power and implementation costs.
> 3. N events look ahead.
> There is a quite difference between 0 and 1; the one node buffering
> allows e.g. to join consequent text events into a single node (which is
> required by the XPath data model).
> 4. Position counters (to enable position predicates and position() function)
This is low cost. I'd have no qualms about collecting it. It
breaks down if there are many different element names.
> (Please, add more ...)
This assumes an XPattern engine that iterates the various axis.
I'm still interested in a deterministic algorithm.
There are cases like this that I'm encountering.
Transforming this:
<request>
<path-info>
<path>blogometer/2005/01/01/dfa-snippits.xml</path>
</path-info>
</request>
Into this:
<request>
<path-info>
<path>blogometer/2005/01/01/dfa-snippits.xml</path>
<exploded on="/">
<step>
<path>blogometer</path>
<step>
<path>2005</path>
<step>
<path>01</path>
<step>
<path>15</path>
<step>
<path>dfa-snippits.xml</path>
<exploded on=".">
<step>
<path>dfa-snippits</path>
<step>
<path>xml</path>
</step>
</step>
</exploded>
</step>
</step>
</step>
</step>
</step>
</exploded>
</path-info>
</request>
Hmm... Okay, sorry for the verbose example, it's what I'm
working on right now.
The idea is that in order to place the exploaded element, I need
to select:
/request/path-info/path/text()
And I need to match:
/request/path-info[path]
Or maybe even:
path[contains(text(), '/')]
Which strikes me as resonable, but not, to my understanding, a
question of look *ahead*. More like look behind.
--
Alan Gutierrez - alan@engrm.com
|
