[ruby-talk:26406] Re: Why not xmlparser? (was: Re: XML support in the standard lib;whatexactly?)

On 01/11/24 11:18 AM, "Sean Russell" <[e-mail]> wrote:
> James Britt (rubydev) wrote:
>> There has been an interesting thread on xml-dev about who is using DOM or
>> SAX, and whether people are making the best choice.  While the majority of
>> XML developers may use a tree, this may be simply because they are
>> unfamiliar with event-based programming.
> 
> Perhaps.  I'd argue that DOM is more OO, while SAX is more procedural, and
> that (therefore) DOM is superior.

Pardon me? I don't agree... at all. I could make a case that DOM is just a
data structure and so not OO at all but inherently procedural -- but I
won't, no matter how much fun that might be :-)

SAX provides an event stream, exactly like a (modern) GUI provides an event
stream. And just like a GUI, an OO application is ideal for handling it.
Unfortunately, there are no frameworks available for XML that do exist, now,
for GUIs. Interestingly, there were no frameworks for event-based GUIs early
on either, and, honest, I had arguments up until at least 1994 over
event-based GUIs, just like we will likely have arguments over event vs.
tree for the next ten to twenty years.

(Sean, I'm not trying to be nasty here, and I hope you don't take what I'm
saying here that way)

>                                    In any case, this isn't a discussion for
> this group, and it certainly hasn't been proven that event-based
> programming is superior.  Suffice it to say that *I* use tree parsing, as
> do most people, and we're not likely to change anytime soon.  ;-P

Hmmm, not proven? ...have you ever had the privilege of working with an
application using a non-event GUI, especially a second release? No proof
would be required, experience suffices :-)

The same holds for XML stream or event parsers (e.g. SAX, XPP). You have the
opportunity to structure your application in a nice OO fashion. The impact
of this is most visible in a large application. Of course in a large
application you would also, likely, be more concerned with performance and
memory requirements, in which case events are the way to go (and you don't
need any other arguments).

BTW, I disagree that this isn't an appropriate discussion for this group. It
is perfectly appropriate I think. These issues will directly impact how
applications are built in Ruby -- or not built in Ruby. This is one of the
more open groups around in this respect, and being new to Ruby though not
new to programming, I've found this willingness to discuss these kinds of
things, and why you do what you do, to be very helpful (even if I disagree
:-)

> 
>> Now, I don't know that Ruby should include something simple because it's
>> what potential users might be most familiar with, if that
> 
> If you include an API that almost nobody uses, they'll use something else,
> and you're back where you started.
> 

Well, the java world isn't all that happy with DOM, if that counts for
anything. We have two well-known and widely used alternatives: JDOM, and
DOM4J.

I am quite firmly of the opinion that this is really about what programmers
are more comfortable with not what makes a better solution. This was dealt
with in the GUI world by developing useful frameworks that used these
events. I would expect that this is going to happen with XML too. This is
why it is important to get the XML parser packaged with Ruby right. If it
isn't then these frameworks will be delayed, or never appear, in Ruby -- and
we don't want that.

What if I were to say that there are classes of applications that will only
be based on event parsers. Consider, as a single example, XML data bindings.
These are tools that generate native objects to represent the structure of
an XML document -- so we are actually talking about families of applications
that are based on a binding rather than just a single application/tool.
There is no way that one of these would consider using any parser that read
and structured the XML document in memory. One of the main reasons to use an
XML data binding tool is to obtain a balance between SAX and DOM... Allowing
a DOM to exist in memory would totally defeat this (actually it would be
worse than 'totally defeat' the balance, it would 'totally defeat' the
tool). A second reason is that an XML data binding can be built more easily
with the event technique (if a DOM was to be used then you'd wind up
processing the tree and faking events).

Cheers,
Bob