[
Lists Home |
Date Index |
Thread Index
]
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)
(Please, add more ...)
Alan Gutierrez wrote:
>Quoting Uche from an off list message:
>
>
>
>>I agree that we should move to XML-DEV and start with a clear
>>statement of goals for the XPattern spec. Seems to me that 6
>>foundational goals are:
>>
>>
>
>
>
>>1) Simple
>>2) Subset of XPath
>>3) Cross platform/language/implementation
>>4) Practical for most streaming implementations
>>5) Supports declarative as well as procedural semantics (the Michael
>> Rhys goal :-) )
>>6) Extensible
>>
>>
>
> I'd like to discuss point six (6), maybe forking a new thread,
> since I'd like to develop a XPath language binding API. I'd like
> to bind the Java extensions I've written for Jaxon to Saxon.
> Like SAX, the API would be expressed somewhat differently in
> different languages, but would allow reuse of extensions across
> XPath or XPattern implementations.
>
> That's one thought.
>
> The second is that I'd like to develop a pattern matching
> engine, so I'd like to see these experssions compile to pattern
> matching automations. I'm not sure how what such a requirement
> will impose upon the langauge. For this application the subset
> of XPath might be larger. I'm not sure it's a good idea, but
> pattern matching seems like a natural for a stream of tokens.
>
> That's a request.
>
> I'll also note that more thought put into streaming will mean
> that documents will be designed for streaming applications. In
> discussion, the argument that real world documents don't always
> convientently have the particpants of a predicate preceeding the
> current node in document order is specious. In the real world
> information isn't always in rows and columns, either.
>
> I'm sharing a realization here, FWIW.
>
> 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/
>
>--
>Alan Gutierrez - alan@engrm.com
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
--
Petr Cimprich
Ginger Alliance
www.gingerall.com
|
