RE: New resource: Normative References to W3C Standards

((This was a TAG issue raised and tabled in the past because the QA documents seemed to cover the situation. If it's being revisited, though ...))

There is an underlying social value also to allowing references to "latest version". 
But there is also an underlying social value that is the source of the requirement that the destination of a reference be as stable as the document containing the reference.

Before abandoning the requirement entirely, it would be best to be clear about what we'd be giving up.

It is now easy for almost anyone to publish specs and make them widely available, or even to organize an informal group or consortium of like-minded people, to manage bugs and establish processes for update, and to insure that copies are available, distributed, archived, backed up, using the processes of open source development to manage convergence, and the ability to "fork" to manage dissent.   You don't need an SDO like W3C (or IETF or ECMA or ...).

So part of the previous value of these SDOs and their processes has evaporated.

But generally a SDO review process also:

* Insures the specs have been reviewed to insure they work for more uncommon use cases and not just the "main" ones.
   For example, while the primary purpose of HTML is for browser use, HTML is used extensively in email, but not all HTML will work
   in an email context.   
* Insure the specs have been reviewed for security, privacy, performance, internationalization, accessibility, even when
   these qualities are not high priority to the primary implementors. 
* Insures that patented proprietary technology is not imported into the platform inadvertently or without notice.
* Provides the ability to create stable test suites to test implementation conformance and interoperability.

and indirectly, provides an audited and documented review process for other SDOs to evaluate.

I think if those goals aren't high priority for you, you probably shouldn't bother with an SDO.

"Living Standard" seems like an oxymoron -- fundamentally a "standard" which can change out from under you is no standard at all.
The "standard" serves as a stable reference point for multiple parties to agree across the world, but it requires the implementors
and independent asynchronous review of the SAME spec.


If spec A refers to spec B normatively using "latest version" reference (rather than a specific dated reference), and B is an editor's draft,
then any attempt to stabilize A via the goals above  will be thwarted, unless the destination of B is taken to be not
the "latest version", but rather the "latest version" that has also survived  a review not only of B, but of the reference
from A to B. 

There may be other ways of handling the dependencies that would be more complicated, but might accomplish the goals of simultaneously allowing referencing the 'latest version' but also being explicit about which versions reviewers were expected to read at the time of review.  

Right now, we use the document status and location and filename to indicate and understand its review and approval status. 

There are a variety of ways the specifications could be arranged to keep the value of stable references while also giving implementors of the specifications a clear lead on where things are likely to go by pointing not only to the stable, reviewed version but also to the latest version. Or perhaps the "last call" of a core platform spec should be accompanied by a "last call" version specification which would indicate both the latest version pointer and also a dated version, for all normative references, of the version reviewed at the time of "last call".

If normative references change between last call and time of publication, it requires some judgement of whether last call needs to be repeated, or if the updates to referenced specifications are innocuous enough not to invalidate the previous "last call".

Larry
--
http://larry.masinter.net

Received on Wednesday, 17 April 2013 20:25:09 UTC