Lists Home |
Date Index |
Eric van der Vlist <firstname.lastname@example.org> wrote:
| On Fri, 2002-09-20 at 23:20, Arjun Ray wrote:
|> The formalization of an infoset spec is not only enough, it makes DOM
| Aren't there places were interoperable APIs are most needed?
I'm not sure what an interoperable API is. Does it mean that a Java API
should work with Python code? It makes quite a bit of sense for a target
language to have standardized OM, but I don't see the sense of a single OM
| What about parsers?
AFAICS, a parser should cover everything in the infoset. The immediate
consumer would be a layer tasked with constructing an object model - or
domain specific equivalent - suitable to the language of the processing
| This is still a major interoperability issue for web developers even
| with recent versions of browsers, maybe not for the DOM,
could have focused on that problem instead of trying to "generalize".
| but we have no way to control for instance client side transformations
| in a browser.
In what environment, though? Cuuld you provide a scenario or use case?
I don't think there is such a thing as language neutral transformation,
except operations on the infoset (which could be done with XSLT, say).
Once you're into the OM layer and beyond, language lock-in is a practical
and pragmatic given.
| there still are contexts in which interoperable and standardized APIs
| are badly needed!
I think "interop" is an overplayed word.
Interoperability means that I can call my barber to make an appointment
and not have to concern myself with what telephone carrier he's using or
who manufactured his phone. It doesn't mean that I can call my barber,
order a pizza, and expect to have one delivered. -- Eric Bohlman