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