xml-dev - Re: SAX Comments

["Thomas B. Passin" <tpassin@home.com>]

There has been a lot of discussion amongst the Python xml group about this,
too.  Not just SAX but DOM as well.  Python has dictionaries (hashes) like
Perl, and lists and tuples as well.  Python users usually like to access
object properties directly rather than with accessor functions.  With DOM, of
course, there is an interface definition in IDL, but that still has to get
expressed for each language.

Matt Sergeant answerd Rob Lugt -

> On Tue, 5 Dec 2000, Rob Lugt wrote:
> ...
> > This is specifically a java binding of SAX 2.0, but I would expect other
> > "compliant" SAX 2.0 implementations to follow the same handler/callback
> > model and to support the same set of callbacks.  The perl/SAX
implementation
> > is significantly different to this in that it has many additional
callbacks
> > not present in the "official" specification.
>
> I still see absolutely no reason to be forced to make the API's the same
> across languages. The old argument of being easy to port from one language
> to another doesn't seem to have any weight behind it (has *anyone* had to
> do this?) when faced with the benefits of supporting a particular
> language's paradigm.
>
> > Is the java binding considered to be the "official" specification?  Or is
it
> > simply the one that is best documented?
>
> Its just the one you know about best, probably. I've not noticed any flaws
> in the current SAX documentation for other languages.
>
>>...

> Perl supports a different programming paradigm to java. Hashes are first
> class objects. It only makes sense to use them there, rather than force
> them into the Java way. That happened with Perl's XML::DOM module, and
> many people don't like having to use Java semantics to program their Perl
> code.
>
> It comes down to a simple question: is cross language portability really
> that important for SAX?

Since there is never that much documentation, it's good to try to be as
similar as possible to any reference versions.  That helps you to start using
the API with minimal problems, because you can predict what the syntax will
be.  That's useful.  Otherwise, make use of a language's strengths but keep to
the underlying conceptual design, I'd say.

Tom Passin