[
Lists Home |
Date Index |
Thread Index
]
Eric van der Vlist <vdv@dyomedea.com> 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
|> irrelevant.
|
| 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
that Java, Perl, Python, Tcl, Javascript, VB and whatever else must all
share.
| 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
environment.
| This is still a major interoperability issue for web developers even
| with recent versions of browsers, maybe not for the DOM,
Well, yes. The DOM has its origins in incompatible Javascript OMs. They
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
|
