W3C home > Mailing lists > Public > www-tag@w3.org > January 2012

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

From: Larry Masinter <masinter@adobe.com>
Date: Wed, 18 Jan 2012 05:54:58 -0800
To: Robin Berjon <robin@berjon.com>
CC: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <C68CB012D9182D408CED7B884F441D4D06125199D1@nambxv01a.corp.adobe.com>
> What is too complex and ultimately wrong  is to give options to those 
> writing specs that make references.

> I beg to differ. Ultimately, those who write specs are those most 
> informed about how they should handle their own references
>  (if they're not, then we have an entirely different problem). 
> They are the ones who should be making decisions about whether
>  the specifications they reference can be trusted to remain compatible
>  and should therefore be loosely bound, or on the contrary (hopefully 
> only in extreme cases) have a broken upgrade path and need an anchored reference.

I don't think it is an "entirely different problem", I think it is the
essential problem we have to fix. 

Spec A references spec B normatively (for definitions of terms, possibly
for normative constraints, whatever.)

Specs have editors, reviewers, and implementors. 
The workflow is that editors write the specs, reviewers review it for
implementability and interoperability and IPR and other values,
and implementors implement the spec (later). 

What do editors of spec A write, what should reviewers of spec
A assume, what should implementors of spec A do, when the editors
of spec B issue B', an updated spec.

What are the failure modes, and what can we (W3C) do, in terms
of managing references and establishing guidelines, to prevent
the failure modes or at least call attention to them?

Of course it is useful to look at other SDOs and their attempts to
manage this (in ISO and in IETF), and also to have some use cases
in mind.

I have a large number of use cases in mind -- references to Internet Drafts
In the HTML document, the widget spec reference(rec) to the sniffing
spec, the SVG reference to XML 1.0, the difficulties with references
to URIs, IRIs, LEIRIs, Web Addresses (where it isn't clear which of these
are 'updates' to any of the others), references to specs in MIME type

I agree that it *should* be the case that those making the reference
*should* be able to judge the stability and likely growth of the
specs that they reference.

However, even with best of intentions, things happen,
(1) specs have errors and you should be able to correct them. 
(2) new extensions are both useful and harmless, you should be
 able to use them, but
(3) people get carried away with enthusiasm, and stuff gets added
or changed in B in a way that is harmful or disruptive to A.

In addition, unfortunately, not everyone always has the best of
intentions, e.g.,  where subtle changes to A might be hidden in an
apparently locally innocuous change to B.

A set of guidelines from W3C should establish guidelines:

What should the editors of spec A write?
What should reviewers of spec A presume about B  when they're evaluating
A for rec/standard/implementability?
What should implementors of A assume?

The TAG can write those guidelines and get the membership to agree
to them.

What can we actually optimize here?

What I think we can't do much other than manage the review process
and the integrity of statements around it:

If someone asks "my implementation X conforms to A", can we provide
a clear definition of what that means? In a way that everyone involved
in the process ... from the reviewers of A to the implementors of A to the
people buying and selling implementations of A ... agree on what that

> Of course editors need to be aware of this decision in the first place, 

Which decision? That the editors have the responsibility to predict events
in the future that are completely outside their control?

> hence the usefulness of a Best Practice discussion the issue. 

I think it is useful to establish best practices, but to be clear about what
we're trying to optimize.

> But beyond that, removing options from smart people who are better-
> informed about their problem domain than we could ever be does not strike
>  me as particularly helpful.

I think it is useful to remove options for misinformed optimism, misinformation.
I'm not stuck on my solution, but I hope this expanded discussion makes
it clearer where I'm coming from.

> I think that Henry's original proposal captures the two important pieces of 
> information: the version of referenced specifications against which the WG
>  developed (and tested),

I agree this is important, but note that it removes from editors the option 
of not saying this at all.... what if the editors would rather make an undated
normative reference to a living standard?

Shouldn't that be an option? If you trust the people editing B that
they'll not make incompatible changes that will cause you a problem?

What if the editors of A have a different trust model than the reviewers
of A or the purchasers of products claiming conformance to A?
They "should" know, but the trust model isn't explicit and is difficult
to review.

> and its reliance on referenced technology remaining compatible in future.

The real problem is to balance the needs of editors who don't want to
do too much unnecessary work that doesn't matter, reviewers who 
may not be versed in the nuances of standards politics or what trust
is implicit in a loose reference, implementors who want to sell products
 that are either stuck with old implementations (and don't want to be held 
accountable for conformance against specs that weren't written when
their implementations were made, vs. implementors who have updated
 and want to sell their stuff against products that haven't.

Received on Wednesday, 18 January 2012 13:55:49 GMT

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