Re: Best practice for referring to specifications which may update

Michael Sperberg-McQueen writes:

> 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'm somewhat head down trying to finish a TPAC presentation, so won't 
respond to all your other points just now.  On the above, that's not quite 
my recommendation for a TAG position.  What I intended to suggest was:

"Loose coupling (or future proofing) is typically good practice and is 
generally encourged.  The TAG does recognize that there may be situations 
in which such loose coupling is dangerous or just less effective than 
tighter coupling, so this is guideline, not a requirement."  So, not 
neutral.

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

That's probably the main source of confusion.  Strictly speaking, I 
suppose you're right that calling it a "best practice" leaves wiggle room, 
but my preference would be for being  a little clearer about it.  I've 
observed that even best practice statements by the TAG tend to be wielded 
as cudgels when convenient for one party or another, so I tend to err on 
the side of being extra-clear as to how strong our recommendations are. 

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
10/28/2009 12:04 PM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, 
ht@inf.ed.ac.uk (Henry S. Thompson), www-tag@w3.org
        Subject:        Re: Best practice for referring to specifications 
which may update



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:35:53 UTC