[
Lists Home |
Date Index |
Thread Index
]
On Saturday 19 February 2005 19:12, Elliotte Harold wrote:
> 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.
We clearly have very different objectives here. I think
maybe at the core is that a LCD model is always going to
compromise performance. I am tied of working with models
that do this because they make my job harder.
I can see why something simpler is appealing but think they
are often short sighted in a way. When one of the
limitations becomes a problem, off we go and create yet
another model with just slightly different properties.
I was hoping there might be a way out of that circle. Maybe
I should go off and think about how I would tackle this a
bit more coherently. Thanks for enlightening me about why
things go this way.
Kev.
|
