[
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
interface.
> 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!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
|
