[
Lists Home |
Date Index |
Thread Index
]
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.
|
