Great discussion. It's not interoperability we're talking about, as that's taken care of by XML. It's not portability of code that we're talking about either: code written to an interface in Java is not portable to C in the way that the same interface may facilitate portability from architecture to architecture in C. Rather it's the programmer's ability to contribute regardless of the language being used. Standardizing an API such as DOM across different languages is a nice goal. When I see a few lines of XML traversing code written in Ruby using DOM I immediately know what it's doing despite the fact that I've never coded a line of Ruby in my life. The reality is practically any API that standardizes something as complicated as what DOM attempts is going to have to be shoehorned to fit into the worldview presented by many modern languages. But the DOM will always be familiar to the programmer. Practically everyone can agree that is a Good Thing (unless you're going to start arguing that the monopolization stifles innovation or rather the adoption of new innovations, but that's off topic). On Fri, 2006-03-31 at 12:36 -0800, Tatu Saloranta wrote: > > --- Robin Berjon <robin.berjon@expway.fr> wrote: > > > > It is an urban legend. How you use the DOM varies > > not only from > > language to language but also from implementation to > > implementation. > > But this is beyond the point -- it's the perception of > DOM usage being the same. Managers only see this > supposed increase in inter-operability (which, like > you point out, is a fallacy in reality). > > > > Part of the reason of which probably is that, > > since > > > DOM was created FOR Javascript (standardized what > > > Netscape had built for its needs) > > > > No, I don't think that's true. If the DOM had been > > created for > > Javascript it would be a *lot* less horrible than > > all the hoops it > > had to jump through to support utterly braindead > > languages like Java. > > Huh? Yes, going towards lowest common denominator > caused even more problems (more so than cleaning up > some of NS mess -- yes, DOM standard did some cleanup, > after NS hacked 'version 0'; but no fundamental > changes): but those have little to do with Java, and > more to do with scripting vs. non-scripting language > differences. > Fact is that "DOM0" (model Netscape created for its > browsers, and that was the starting point for DOM > standard process) was written for a scripting language > (Javascript -- or, they co-evolved); and of course it > then happens to be more convenient to use from a > scripting language than from a more static language > (Java, C/C++, C#, ...). > Programming languages generally show traits of what > they were built/planned to be used for: C for writing > OS, Pascal for teaching CS, C++ for phone switches (or > something more sinister judging by its complexity), > Java for multiple things during its development (1.0.2 > seemed like it was designed to be used for > implementing web browsers). Ditto for APIs: even > though DOM was to be cross-language, it still has its > roots in that dang Netscape browser, cobbled together > to allow nifty new dynamic features. > > And of course its use for XML was an afterthought as > well: it all started with HTML. Is it any surprise > that namespace support, then, was an ugly bolted-in > monstrosity? Few people then understood namespaces, > and not many do now. > > Barking at Java is pointless; all the other current > mainstream OO languages (plus C) would have similar > constraints on API design; and like Elliotte pointed > out, everything for everyone (aka "general solution to > the general problem") is a recipe for failure. > > -+ Tatu +- > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://www.oasis-open.org/mlmanage/index.php> > -- Charles Woerner Integration Engineer Ensenda, Inc. cwoerner@ensenda.com (415) 277-2030
Attachment:
signature.asc
Description: This is a digitally signed message part