[
Lists Home |
Date Index |
Thread Index
]
Eric van der Vlist <vdv@dyomedea.com> wrote:
| 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:
| >
| > I'm not sure what an interoperable API is.
| I was meaning interoperable for a specific language.
Well, that's an issue for each language community unto themselves, isn't
it? The patterns could be similar, but the idioms *will* be different.
Interop does not mean "one size fits all", but all too often these days
it's taken to mean just that. Buzzwordification.
|> AFAICS, a parser should cover everything in the infoset.
|
| Aggreed, it's infortunate that the APIs which are using today have been
| designed before the XML infoset was clearly defined
A historical accident. The misfortune is that the APIs have been frozen.
| and also (IMO) infortunate that there is no XML serialization of the XML
| infoset
I think you mean a *canonical* XML serialization. I don't see the problem
in devising something akin to CGRs, so I'm not sure why this lack is a
misfortune per se.
| (and that the PSVI wants to follow the same path -a different story and
| one of my favorite rants-).
My eyes glaze over and my mind goes blank when I hear "PSVI".
|> 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.
Great heuristic! We can't solve this problem, so let's generalize it (as
in, "Why should this be only our problem? Let's make it everyone else's
problem too!")
|>| 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?
| 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.
Shades of Greenspun's Tenth Law.
| 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.
I've always maintained that XSLT as an "XML application" was a brain
damaged idea. This is precisely the sort of abuse I had in mind. For
better or worse, the XSLT folks resisted the call for a fully articulated
macro and eval facility, as in say Common Lisp - in other words, dynamic
evaluation as part of XSLT itself rather than silly DOM-style 'scripted'
jiggering of arbitrary portions as a "document" - and this is the price
being paid.
For this use case, what was wrong with the *DOM* layer supporting a "sort"
function? It all sounds so bewilderingly hightech - Oh, I futz with the
XSLT, reapply it to the input, an get myself another DOM instance - when
this is just the document.write() minsdset with more dangerous tools at
hand.
|> 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?
For a pizza?
|
