Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What should TrAX look like? (Was: Re: Article on
 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, http://www-dbs.informatik.uni-heidelberg.de/publications/vldbj.pdf 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. Kev. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
