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

On Jan 17, 2012, at 7:10 PM, Larry Masinter wrote:

> What is too complex and ultimately wrong  is to give options to those
> writing specs that make references. 

I'm not sure how you can remove the necessity for WGs to make choices
in this area without breaking something.

If you say all bindings are loose, all the time, you risk forcing a loose
binding where what is really needed or intended is a tight binding, after all.

If you say all bindings are tight, all the time, you risk making it harder
for any spec to be revised and improved.  ("There's no point in fixing this
bug, because all the specs that use this one have already referred to
version 1.0, and they won't be able to use version 1.1 anyway.  So
why bother?"  I'm not imagining this argument, but remembering it.)

Sometimes tight coupling is wanted, sometimes loose coupling is
wanted.  The WG writing a spec must make that choice.  The best thing
anyone in the position of the TAG can do is make clear what the choice
is, provide some guidance about how to make the choice, and suggest
some wording for signaling the choice.

> "loose bindings" can't be automatic, because there is no way to control,
> But normative references should not automatically require updating
> the referencing spec;

That's a good way of putting one of the key arguments in favor of
loose bindings:  if a reference from spec A to a specific version of 
spec B is interpreted as a reference to that version of B AND NO OTHER, 
then it does become necessary to update spec A every time B is
updated.

Much better to make clear in the normative reference that such
updates are not needed, and that implementations MAY support later
versions of spec B without losing their claim to conform to spec A.

> if there are incompatible changes, then the update
> might be made by publishing an applicability statement instead, though.

If a language lawyer argues that a reference to spec B is only a 
reference to the specific version named, and not to any later version
(as has been argued in WGs I have participated in), such a statement
would have no effect.  The spec says I must use version X of spec
B -- the WG can't change that by publishing a different document.

An applicability statement can have normative effect only if the original
text of spec A makes clear what the effect of normative references is,
and that a normative reference to version X of spec B may (in the
presence of a separate applicability statement from the WG) be
taken as a reference to other versions as well.

If you'd like that to be workable, you really are going to have to suggest
wording for use in the normative references section of the spec; I have
no idea how to draft such a notice clearly and concisely, in such a way 
that it could be used to block the contrary tight-binding interpretation.

> 
> All references should be 
> (a) dated, versioned editions in the link
> (b) by default, all references are "loose bindings", without
>  any explicit disclaimer.

Without any explicit statement that they are loose bindings?

I used to believe that loose binding was the obvious default meaning of any 
normative reference.  But I have encountered plenty of WG members who
argue the contrary -- some of them now sit in the TAG, so they can perhaps
explain their logic to you in more detail.  But even without understanding their
logic, it's possible to note that without an explicit statement in a spec that
all references are loose bindings, some readers of the spec will assume that
all references are tight bindings.

Doing without any explicit disclaimer is a non-starter, given that some
smart people argue that versioned references are by default tight bindings.

> 
> To confirm that a reference is appropriate, W3C working groups could
> be encouraged to publish applicability statements, e.g.:
> 
> "Working group finding:
> 
> Spec A is still valid with B.v1 replaced with B.v2 and C.v1 replaced with C.v3
> (except note that referenced section 3.6 in C.v1 is now found in section
> 7 of C.v3)."
> 

This seems to suggest that no working group can ever safely go out of
existence without endangering the ability of users of their specs to update
their Unicode libraries etc.  

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

Received on Wednesday, 18 January 2012 17:13:13 UTC