Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@m... 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
|
