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


Help: OASIS Mailing Lists Help | MarkMail Help



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

[ Lists Home | Date Index | Thread Index ]

I think we've all implicitly agreed that Source is pretty useless. The 
primary argument in its favor has been a lot of hand waving and pointing 
at some .NET thing, and saying, "That's even worse" but nobody's really 
stepped up to defend Source on its own merits.

Here's a perhaps more useful question. Could we define an alternate 
source interface that would allow validators, transformers, and query 
tools to hook into arbitrary models? Specifically, could we define one 
that would be complete, unlike Source; and would not require these tools 
to provide special support for each different object model? What would 
such an interface look like?

It is, I admit, a hard problem. I suspect it could be solved for 
tree-based models by defining some sort of interface based on the XPath 
data model. I am not at all sure it's possible to define this for 
streaming models as well, but perhaps it is.

Possibly the issues of transforms are different from query tools and 
validators. All transform engines I've seen build their own internal 
model. They do not work directly on top of DOM, SAX, XOM, or other 
things. Validators and query tools, by contrast, tend not to construct 
new object models and do work directly on top of the preexisting 
in-memory representations of the XML document.

If that's an accurate characterization (I'm not sure it is) then the 
needs of transforms would be served by a single interface that just 
streamed entire documents into the engine, because the engine is going 
to build a new model anyway. On the other hand, query tools might want a 
wrapper around an existing tree model that they could query. Validators 
could probably work with either.

I'm not sure it's possible to satisfy all use cases with one or other, 
but maybe it's possible. If not, perhaps we could get away with two 
interfaces instead? e.g. replace SAXSource and DOMSource with 
StreamSource and TreeSource. These would be read-only interfaces that 
would provide full access to what's needed for the XPath data model. 
Each model could implement one interface or the other. Tools could 
support one or the other, but I think most would support both. However, 
they would only need to support both. The would not need to specially 
support JDOMTreeSource, XOMTreeSource, DOMTreeSource, SAXStreamSource, 
StAXStreamSource, XNIStreamSource, etc.

Does this seem plausible? Does this seem worth doing? Does anyone have 
any other ideas?

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