W3C home > Mailing lists > Public > www-tag@w3.org > October 2009

Re: Best practice for referring to specifications which may update

From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
Date: Wed, 28 Oct 2009 10:04:21 -0600
Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, ht@inf.ed.ac.uk (Henry S. Thompson), www-tag@w3.org
Message-Id: <F53BA639-A785-44C6-A1F0-883A81B090A0@blackmesatech.com>
To: noah_mendelsohn@us.ibm.com

On 28 Oct 2009, at 09:20 , noah_mendelsohn@us.ibm.com wrote:

> Henry Thompson writes:
>
>> Comments welcome.
>
> I think this is good for the common case where you >do< want to
> future-proof your references, as in:
>
> "Conformant implementations may follow the edition cited and/or any  
> later
> edition(s). "
>
> I do think it would be a step too far for the TAG to imply or  
> require that
> such language be used in all cases.  I can easily imagine cases in  
> which
> what's desired is to specifically require use of the "edition  
> cited", or
> else to allow only later editions meeting certain criteria.


I think the notion that there might be exceptions is implicit in the
concept of "best practice", so Noah seems to be fighting a straw man
when he suggests that Henry's wording implies a requirement that the
language he lays out must be used in all cases.  He certainly
doesn't seem to be engaging with the proposal actually made.

There may be a real disagreement here, on how strongly the TAG
should recommend loose coupling.  Noah's language suggests he would
rather the TAG be neutral on the matter.  I think that neutrality
would be a mistake: loose coupling is an important architectural
principle.  The TAG should recommend that WGs provide for loose
coupling of their specs to their dependencies in all cases where
they do not have very compelling reasons to do otherwise.

On a minor point: Noah is right to suggest that it would be useful
for referring specs to identify concretely which aspects of the
specs they refer to are essential and which are inessential, so that
it's clear when a later version can be used without contradicting
basic assumptions in the referring spec.  I'm not sure such lists
are likely to be easy or popular, though.  An early draft of WSDL,
for example, was exemplary in describing which aspects of XML and
XSD it depended on, and which could be changed in later versions of
XML and XSD without causing problems for the WSDL spec or for
conforming WSDL implementations.  Unfortunately, all that material
was later excised as unnecessarily complicated, during an attempt to
mollify critics by simplifying the spec.

In the absence of such explicit lists of crucial assumptions about
the specs referred to, I think a blanket permission to use later
versions of those specs is still usually safe by default: if the
later version of the other spec contradicts fundamental assumptions
of the referring spec, then any implementation that attempts to use
the later version will encounter logical contradictions in its terms
of reference, and will find it impossible to use the later version
of the other spec.  If the use of the later spec is logically
impossible, then explicitly prohibiting its use has no benefit for
interoperability.  On the other hand, if using the later spec does
not lead to contradictions, then there is definite harm in
forbidding its use.

It would be ironic for W3C specs to be more conservative and less
flexible in this regard than those of ISO.

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************
Received on Wednesday, 28 October 2009 16:05:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:18 GMT