Re: Web standards, Openness and Transparency

On Tue, Aug 12, 2014 at 7:17 AM, Marcos Caceres <marcos@marcosc.com> wrote:

> On August 11, 2014 at 3:51:54 PM, Chris Wilson (cwilso@google.com) wrote:
> > > Note that I'm not EXACTLY advocating for this; I actually think
> > directly using living documents in /TR is not a good idea.
>
> Can you provide the rationale as to why?
>

Perhaps it's my impression of what most people mean by "living document".
 There are different degrees of "baked", and I've seen some things go in to
living documents that I don't think necessarily represent rough consensus;
that makes it quite hard (particularly in a large specification) to tell
what's implemented everywhere, what's pretty solidly agreed upon, and what
is just a roughed-out idea.

You could, of course, use editors' drafts here, and have the living
document always represent rough consensus (i.e. EDs are branches) - and I
certainly agree we need a faster update cycle in /TR, and
I think of specs like software in this sense.  We have a fast release cycle
for Chrome - at the same time, we have different channels, and they are
different levels of done.  Yes, we want

>
> > It *IS*
> > a good idea to make sure /TR documents always POINT to the current
> > spec or effort (yes, including pointing to editor's drafts).
>
> This is what we have today, no?
>

Absolutely not.  There are some specifications that do this, it's true -
but many do not.  For example, a couple of weeks ago I was trying to dig up
information about the "TV" media type.  I started with CSS2.  I dug through
a lot of (unlinked) specs (e.g. CSS3 media queries, HTML) before
discovering the new CSS Media Queries level 4 document, which effectively
completely replaces the bit I was interested in.  None of the specs in /TR
hinted that there was superceding work going on.

(There ARE definitely counter-examples here.)

> I think redefining history of specs is bad.
>
> Not sure what this means. Can you provide an example?
>

Any time you simply rev in-place without significant versioning, you're
effectively changing history.

> I think making it clear
> > - MOST clear - what current status is, is critical.
>
> Agree. Knowing status is critical.
>

And to be clear - I think /TR/HTML *should* point to the latest and
greatest HTML.

>
>
> --
> Marcos Caceres
>
>
>