Next in thread → Next in month →

Re: [xml-dev] DOM's javascript roots (was Re: [xml-dev] Have JDOM / XOM / etc. failed?)

From
Tatu Saloranta <>
To
Date
2006-04-26T21:54:19Z
ID
<>
Thread
Re: [xml-dev] DOM's javascript roots (was Re: [xml-dev] Have JDOM / XOM / etc. failed?)
--- Gavin Thomas Nicol <> wrote:

> 
> On Apr 25, 2006, at 4:29 PM, Tatu Saloranta wrote:
> 
> > Namespace handling is an absolute mess, and
> > alternatives I have tried (JDOM, XOM) all
> implement in
> > less messy way, and significantly so.
> 
> FWIW. Namespace support was 'tacked on' to DOM, just
> as it was to  
> XML. It was totally superfluous then and has simply
> complicated  
> things since IMHO. DOM is a good case in point.

Yes, I understand that the sequence of events made it
hard to retro-fit namespace support. DOM was
engineered prior to namespaces. I mentioned this,
though, since it's one area where other alternatives
have fared better (having been fortunate enough to
start later, partially).

> >> That said, I rarely use DOM anyway: I do almost
> >> everything in SAX...
> >
> > That's pretty hard-core. ;-)
> > (due to SAX imposed "involuntary
> > inversion-of-control")
> 
> Not really... how often do you *really* want the XML
> in DOM in your  
> application? I very rarely do... though I use XML as
> a storage format  
> a lot.

Me neither, actually, but for tasks I usually do, pull
parsers are somewhat easier to use (but as usual,
YMMV). At the same time, what I really would like to
see (and am trying to work on, on the side, with
StaxMate project), are utility libs/frameworks that
allow refinements of stream-based processing, without
requiring full in-memory modelling. And obviously many
other people are working with similar ideas too.

-+ Tatu +-


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com
Next in thread → Next in month →