[
Lists Home |
Date Index |
Thread Index
]
On Sat, 2002-09-21 at 01:07, Arjun Ray wrote:
> 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.
No, I was meaning interoperable for a specific language.
>
> | 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.
Aggreed, it's infortunate that the APIs which are using today have been
designed before the XML infoset was clearly defined and also (IMO)
infortunate that there is no XML serialization of the XML infoset (and
that the PSVI wants to follow the same path -a different story and one
of my favorite rants-).
> | 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".
Probably since the problem hasn't been totally solved.
> | 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 are many examples around of client side XSLT where (for instance)
when a user clicks on a button a sort order in the XSLT transformation
is modified in Javascript using DOM on the XSLT document and the
transformation reapplied on the same document without any interaction on
the server.
I think that this is probably one of the most frequently given example
of the benefit of client side XSLT and few people realize that this will
most probably never work on any browser but IE since the Javascript API
to get the XSLT document applied on the XML as a DOM and to request that
the transformation is reapplied on the XML document isn't normalized.
Extending DOM, we would need JAXP and TRAX APIs for Javascript in a
browser context but I am not sure how many people have even suspected
that there is such a need :-( ...
> | there still are contexts in which interoperable and standardized APIs
> | are badly needed!
>
> I think "interop" is an overplayed word.
Probably and that a browser is a very specific environment too where you
ship code to virtual machines provided by fierce competitors who use to
think that vendor lock-in is their best weapon.
> --
> 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
It's a good image, but don't you expect your barber to speak the same
language too and understand that you're trying to make an appointment?
Eric
--
Rendez-vous à Paris.
http://www.technoforum.fr/integ2002/index.html
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
|
