Re: [xml-dev] XML processor behavior with unused NS declarations

["C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>]

On 14 Jul 2009, at 12:12 , Len Bullard wrote:

 > At what point does it become reasonable to expect the
 > specification to be changed/improved/evolved/complicated to
 > describe expectations in non-normative sections?

In the general case, it's reasonable to expect a spec to be
revised when revision serves the interests of a large enough (or
powerful enough) group, just as it's reasonable to expect initial
development of a public spec when that initial development serves
enough people.  In the case of revision, the risk inherent in any
revision (what if the WG is filled up with crazy people who
destroy the value of the spec? -- Look what happened with ISO
standardized EBNF!), the cost of non-revision (is the absence of
the desired revision actually hurting anyone?  is it hurting
enough that they will put resources toward repair, or only enough
that they will complain on public mailing lists?), the cost of
any necessary changes, the likelihood of success, and doubtless
other factors all need to be weighed.

In the case of XML and this particular aspect of it (the
specification of what a parser must tell its downstream app), it
looks to me as if:

   - No one is suffering very much from the failure of the XML
     spec and the Infoset spec to specify a parser output info
     set, perhaps because there are separate specs like SAX and
     DOM for that, perhaps because in fact market pressure
     suffices for this sort of thing after all (who would have
     thought it?).

   - Relatively few organizations and individuals seem to be
     eager to spend resources championing, leading, or serving in
     a revision of XML, or even in ongoing maintenance of the XML
     spec -- at least not judging by public information about the
     membership of the XML Core WG.  Perhaps they would rather put
     their resources elsewhere.

   - The world is full of people with ideas about how to make
     XML better, or at least different, and chartering a group to
     produce an XML 2.0 would bring large numbers of them out of
     the woodwork, determined to help the WG bring order and
     rationality to XML and overcome the benighted decisions made
     in 1996, or even those made in 1986.  It may look to some
     current XML users as if there were some risk that too
     flamboyant a revision of XML might destroy its current
     benefit, and also some risk that it would take a long time
     and a lot of work to prevent a disastrous result.

Concretely, I for one would really enjoy the challenge of
re-formulating all the core specs to reflect what we now know, to
do them 'right' (at least, as we now perceive what it means to do
them 'right') and to dot all the t's and cross all the i's.  But
I do not expect such work to be possible without a charter to
produce a major revision of the specs.  And if any working group
is given a charter to produce a major revision of the specs, I
think they will find it difficult to limit themselves to filling
gaps, firming up implicit assumptions, and harmonizing things.
(Even apart from the difficulty writing a charter which is at
once sufficiently liberal to allow the appropriate changes and
sufficiently restrictive to forbid most harmful changes, very few
organizations and individuals want to devote 20% or more of a
qualified engineer's time for a few years to develop a suite of
specs that will be summarized as "mostly leaves well enough
alone".)

So personally, I no longer think it reasonable to expect any
major cleanup of the XML spec.  The risk / cost / benefit
equation just looks out of whack to me.  Even the minor cleanups
of XML 1.1 have been met with an avalanche of fear, uncertainty,
and doubt (currently being replayed with XML 1.0 Fifth Edition in
the role of XML 1.1, for those who missed the show the first time
around).

YMMV, of course, and I could just be wrong.

Re-reading this and your comment, I realize you spoke of
non-normative sections in the spec.  I think if we are willing to
settle for non-normative expectations, SAX and DOM and other
interfaces seem to have done a satisfactory job of setting
expectations already.

 > Isn't that where the appellation of XML as a specification
 > becomes XML as a standard?  After all, it isn't a private wine.

I think you may be postulating a distinction between 'standards'
and 'specs' which I don't fully understand.

ISO 8879 also does not specify what information a parser should
provide to a downstream application, and the efforts made in the
1990s to supply that gap do not fill me with optimism.  They were
very interesting exercises, both technically and
terminologically, but they did not make SGML technology much
simpler or much more interoperable.


-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************