Re: ACTION-350: Best practice for referring to specifications which may update

On Jan 17, 2012, at 2:45 PM, Noah Mendelsohn wrote:

> Larry,
> 
> Checking through action items, I see that you have marked ACTION-350 as PENDING REVIEW, and included in a note there from you proposing the following path forward:
> 
> ========Start note in ACTION-350=============
> My conclusion is that the advice in http://lists.w3.org/Archives/Public/www-tag/2009Oct/0075.html is too complex and ultimately wrong.
> 
> If spec A references spec B normatively -- i.e., the conformance rules of A depend on following the the conformance rules of B,

Is this the only form of normative reference? 

I'm inclined to think not.

If spec B defines some terms, and A refers normatively to those definitions, then
the definitions in B become a normative part of A:  it is the definitions in B that
govern the interpretation of some terms in A.  Is it not possible to do this without
making conformance to B a pre-requisite for conformance to A?

Some specs (e.g. XSD part 2: Datatypes) refer to the XML spec for their normative 
definition of constructs like Name, Char[acter], and whitespace.  That doesn't
-- or at least, that shouldn't -- imply that in order to provide a conformant validator
for the xsd:integer datatype it's necessary to be a conforming XML parser.  

> then
> 
> 1) the reference in a spec being considered and reviewed should include a specific version.

This is not a change from the approach in 
http://lists.w3.org/Archives/Public/www-tag/2009Oct/0075.html,
so I assume this isn't what Larry Masinter thinks is too complex and
ultimately wrong.

> This is so multiple parties reviewing spec A and discussing whether it should progress can make sure that if they think they agree, they're agreeing about the same thing.
> 
> 2) It is natural to want to upgrade when there is a newer edition of B. But implementations which wish to conform to an specific edition of A but a later edition/version of B should be explicit about which editions they're claiming conformance with.

This is also not a change, except in replacing the words "It is
implementation-defined which editions are supported" with 
a weaker rule (SHOULD instead of MUST) expressed in a 
confusing way (I think the phrase "which editions they're claiming
conformance with" is intended to mean which editions *of B* they
are claiming conformance to -- but for reasons described above,
reliance on a new edition of B does not necessarily take the form
of claiming conformance to B).

> Weasel words in the spec itself aren't helpful.

True.  But I think also not a change.  

What exactly is it that seems too complex, or wrong, in message 0075?



> An alternative would be, at the time A is being devleloped, to explicitly leave the reference unbounded (i.e., point out that B is evolving simultaneously).
> 
> However, specifications that reach CR should resolve these as much as possible, and specs that reach REC should not have any hidden "upgrade" paths via referenced specs.

This sounds like a suggestion that processors conforming to A should not
be allowed to support a current version of B, once the version cited by A is
made obsolete.  I think that's wrong:  in many situations the whole point of
a normative reference from spec A to spec B is to achieve loose coupling
between specs, and forbidding implementations of A to support current
versions of B is a form of tight coupling.

I hope that wasn't what was meant. 

> 
> 
> P.S. I'm taking the liberty of cc:'in Michael Sperberg-McQueen, who was among those on the Schema Working Group who had strong feelings about all this, as I recall.
> 

Thank you, Noah.  I do seem to have strong feelings on the topic:  the
first specs I read carefully were ANSI and ISO specs which normally 
(a) referred to specific editions of other specifications, and (b) explicitly
said that users of spec A should consider the possibility of using newer
versions of spec B, if newer versions are available.  As a WG member, I
was completely blindsided by the argument forcefully brought forward
within a W3C working group that dated references should be interpreted
as a tight binding to the edition specified and to no other.  Since W3C
began as an alternative to other standards development organizations 
marked by its lightweight process and speed of development, I find it 
amusing and alarming that people interpret W3C specs as harder to 
upgrade than the ISO specs I studied in years past typically were.

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

Received on Tuesday, 17 January 2012 23:07:36 UTC