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] Articleon

[ Lists Home | Date Index | Thread Index ]

Kevin Jones wrote:

> 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. 

It's an interesting paper. There are some good ideas in it, but I think 
  it doesn't really indicate in any way that a more functional Source 
interface wouldn't help. This paper proposes a different data model. 
Many engines do use their own data models and implementation strategies. 
That's fine. These are always going to construct their own custom data 
model from existing models because DOM/SAX/XOM/etc. are not going to do 
it for them. What they would get from an LCD interface is a way to write 
the code that converts into their internal representations that is 
independent of the specific model used. Currently, something like BEA's 
XQuery engine has to accept XOM, SAX, DOM, etc. They have to write a 
custom converter for each of these. If there were an LCD interface that 
were rich enough to populate their internal data model, but no richer, 
then they would only have to write that conversion logic once. 
Furthermore, they could easily support object models they didn't even 
know about, as long as those models provided an adapter to the LCD 

> 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 think a symbol based interface is way beyond LCD. As Donald Knuth 
warned us, "Premature optimization is the root of all evil in 
programming." I think names would be exposed as strings that 
implementations could intern or not as they see fit.

> 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. 

But we're not trying to cover the implementation models! All this is 
doing is interfacing with them. The simpler use cases might be able to 
use this directly, without building a new data structure to represent 
the document, just as some tools today work directly on SAX or DOM, but 
any tool that does have a custom data structure would simply populate 
that custom structure from the LCD interface rather than from ten 
different interfaces for ten different models.

Elliotte Rusty Harold  elharo@metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!


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

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