[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: API versioning in SAX

• From: Dean Roddey <roddey@u...>
• To: <xml-dev@i...>
• Date: Tue, 4 Aug 1998 14:00:57 -0400

>> 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.

Hmmm. Ok I'm going to play the "Very Cynical Devil's Advocate" here and ask the
obvious question of "Is a spec that allows 2^7'th conforming variations really
a spec?" If one assumes the normal progression of things as such widely used
specs are evolved in the presence of evolutionary baggage and intsalled base,
wouldn't we likely get up into Saganesque numbers of possible conforming
variations in the not too distant future?

Having worked in a previous life on a large medical software system which was
kind of like the "configurable system from hell" 8-), this type of scheme
always scares me. As the number of possible optional configurations expands,
even if one can confirm that driver X supports your needed features, the
likelihood that use of subset Y of optional features in a particular input file
can cause unexpected, unintended, and/or intertwined consequences that the
writers of the driver just cannot reasonably foresee (or at least reasonably
maintain in a coherent manner as they move their code along in time with
developer turnover etc...)

Anyway, I'm not expecting the W3C to go back to the grindstone just because of
my concerns, but I think they are legitimate concerns. It would serve
everyone's best interests (IMHO) to have a very tight specification in which
there are very few optional reactions to the same circumstances. Given what is
riding on XML (the future of the net?), and given that interoperability is a
key issue that needs to be addressed on the internet, it would seem that a
loose spec is somewhat at odds with the long term goal? The questions being
asked here in this forum are somewhat indicative of a confusing specification,
and we are supposed to be the smart ones <ha, ha>

Just my opinion of course, and I'm widely known to be kinda stoopid :-)

----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
roddey@u...

"Two buttocks always make friction" - African Proverb

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

• Prev by Date: Re: Namespaces and URNs
• Next by Date: Re: Namespace Comments
• Previous by thread: Re: API versioning in SAX
• Next by thread: Do you understand XML namspaces?
• Index(es):
  • Date
  • Thread