Re: New resource: Normative References to W3C Standards

Hi Larry,  

On Wednesday, 17 April 2013 at 9:24 PM, Larry Masinter wrote:

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

What does stable mean to you? I think you are thinking of a "static" draft, not a stable one. Because a static dated draft cannot possibly be more stable that a draft that has been updated to fix an issue or clarify something.    
> 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 ...).
True.  
> 
> 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.

These are not given - but it's good that they do tend to happen at the W3C.  
> 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.
You can still have those things as a priority, and the SDO can still fail to provide those things (or others can provide them). I'm not saying the W3C doesn't provide those things, just that it's like asking "why do you hate freedom?". 
> "Living Standard" seems like an oxymoron -- fundamentally a "standard" which can change out from under you is no standard at all.

I'm sorry, but it seems you don't have a good grasp of what a living standard is. They don't just "change out from under you" - or no more than any other draft on /TR/. The goals of snapshotted and living specs are the same: get implemented and be interoperable. Neither can achieve that is they can "change out from under you", now can they? So it's pretty silly to throw that "change out from under you" FUD around about about living standards. Please stop doing that.  
> 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.

No it doesn't. The WHATWG's HTML specification trivially proves that.
> 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.

So you want B to be a broken and out-of-date spec? nice.

I think most implementers prefer B to be a spec that is maintained, up-to-date, and _actually stable_. That is, stable: that is constantly being fixed and maintained to be at it's highest quality at any period of time. From that point of view, it is unhelpful to point to a dated draft (dated drafts are by definition "dated").   
> 
> 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.

Why? that seems like a waste of time for the reviewers. If reviewer A finds a bug, and it gets fixed - why should reviewer B be subjected to finding the same bug when it's already fixed? That's a good way to annoy your reviewers. 
> 
> Right now, we use the document status and location and filename to indicate and understand its review and approval status.

Some people do, yes - but not everyone (specially people that need to read these specs every day for work). A lot of people just ignore that and go straight to latest because they know that they are *more stable* than stale dated ones. 
> 
> 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. 

Ah! I see where your thinking is different to mine: you think that specs are only periodically reviewed! No no no, that view is totally wrong. As you mentioned, we use better open source tools now to allow our fellow humans to track changes (i.e., no more crappy CVS, less email, etc.). 

In the groups I'm involved with, no change can be made to a spec without having that change reviewed by another WG member or the public before it gets integrated into the spec. That's the magic of forcing everyone to use a Pull Request on GitHub. No change is integrated without a thorough independent review - no matter how small the change is!
> 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".

Has this ever actually been a real issue?  
> 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".

I could be wrong, but I don't remember any lawyers complaining about HTML5's LC references pointing to Editor's drafts? 
http://www.w3.org/TR/2011/WD-html5-20110525/references.html#references

Or for any other spec for that matter. If it ain't broke, don't fix it. The benefits of pointing to Editors drafts, living docs, or latest drafts far outweigh the benefits of pointing to dated drafts. That's easily demonstrable. 

Kind regards,
Marcos

Received on Thursday, 18 April 2013 19:34:55 UTC