API versioning in SAX

[John Cowan]

Dean Roddey scripsit:

> If I'm the administrator of my server or my workstation, and
> I see a new SAX driver out there, wouldn't I just read the README before I even
> downloaded it to make sure that its capable of doing what my current does (plus
> more maybe?)

The trouble is that these are subtle features.  See the post I just
sent out, riddled with MUSTs and MAY NOTs.  Of the 10 items mentioned,
compliant non-validating parsers can vary in 7 of them, which means
there are something like 2^7 classes of non-interchangeable (but still
compliant) parsers.  The docs may not even be specific on these points.

Any SAX app that depends on any of those 7 features better have some
way of checking whether or not the SAX parser supports them, or else
uniformly rely on none of them.

> And, even if I did, the fact that it fails to
> fail on the 3 apps I have now, doesn't mean it supports what I want to support
> on app #4, so I'm going to just read the docs and see what it supports most
> likely.

I think this point is a red herring.  Different SAX apps, due to their
different requirements, may need different parsers.  It's either some
such inquiry mechanism as this, or else have every app keep a list
of "certified" parsers, and have each app writer spend time certifying
every old and new parser.

> Also, once I know what the SAX driver can do, and know that it does what I
> need, why would I want my application playing "20 Questions" every time I run
> it, when I know what the answer is going to be every time? Why waste the time,
> when the kind of situation that you envision might not even happen very often?

It's a cheap check.  Call a getFeatures method, get an int back,
AND it with the feature bits you need, and do a numeric = comparison to
make sure they're all set.  That's it.  Then when you change SAX parsers
in future, your app will either work, or will break early with
an "Insufficiently flavorful SAX parser" error.

> Have you really checked and seen how likely people are to blindly use new XML
> driver software in such as way as to create the problem you've presented to be
> solved?

How can I?  The whole area is so new....

-- 
John Cowan	http://www.ccil.org/~cowan		cowan at ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)