> 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 stil=
l
> compliant) parsers. The docs may not even be specific on these point=
s.
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 conformin=
g
variations in the not too distant future?
Having worked in a previous life on a large medical software system whi=
ch was
kind of like the "configurable system from hell" 8-), this type of sche=
me
always scares me. As the number of possible optional configurations exp=
ands,
even if one can confirm that driver X supports your needed features, th=
e
likelihood that use of subset Y of optional features in a particular in=
put file
can cause unexpected, unintended, and/or intertwined consequences that =
the
writers of the driver just cannot reasonably foresee (or at least reaso=
nably
maintain in a coherent manner as they move their code along in time wit=
h
developer turnover etc...)
Anyway, I'm not expecting the W3C to go back to the grindstone just bec=
ause 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 tha=
t a
loose spec is somewhat at odds with the long term goal? The questions b=
eing
asked here in this forum are somewhat indicative of a confusing specifi=
cation,
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@us.ibm.com
"Two buttocks always make friction" - African Proverb
=