OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] What should TrAX look like? (Was: Re: [xml-dev] Article on

[ Lists Home | Date Index | Thread Index ]

On Saturday 19 February 2005 16:31, Elliotte Harold wrote:
> Kevin Jones wrote:
> If we can define an adapter that's strong enough to
> support XPath 1.0, then I've we've got something very
> useful. Remember, we're not trying to define an arbitrary
> processing model. We just need a least common
> denominator, read-only model that can map between
> different models and XPath engines.

It is certainly useful for some but from my perspective 
another least common denominator solution is less than I 
would want from Source or any other way of exposing data. 
Not sure if that says more about the environment I work in 
rather than anything more general.

> Could you elaborate on this, or provide a reference?
> Would the BEA implementation be unable to work with a
> model that provided the basic axes we're talking about
> here?

There is a paper here that gives some details,

I have never worked with it, but I read it as consuming a 
token stream. I don't know enough of the details to say if 
they could use this type of interface. There are a fair few 
others who handle XPath (to different degrees) without 
using the traditional tree model. 

On more solid ground, one of the proprietary XPath 
implementations I have worked with could probably be 
adapted to use this type of interface but it would be at 
the same time overkill on some features and be short of 
ideal on others. 

As a concrete example (if a little trivial), would such an 
interface support symbol identifiers in place of string 
names. If not, you have a performance issue on Java, if so, 
do you have to convert data streams that don't support 
symbols  before you start processing? If we assume my XPath 
can process either type of data then ideally I want this 
property exposed as a  queryable capability of the 
interface so nobody pays a penalty for the choice they 
made. If I only support the use of strings for names then 
the symbols only input can be rejected as not processable.

I understand you are looking for something way simpler than 
this but I was just hoping to point out that the current 
models are so simple and fixed they are not even covering 
the currently known implementation models, just the current 
majority. If there is demand to re-visit the model then, in 
my opinion, it has to get more complex to match the 
increase in capability of the processing engines that are 
being deployed and we have to manage that complexity to 
make it widely usable.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS