RE: Removing EME persistent-usage-record "at risk" feature

> The TR/ version, code, etc. reference this, and it is the latest version of the REC-track spec.

In order to handle this and to point readers to the current editor’s draft HTML changed its header to include the following links:
http://www.w3.org/TR/2014/REC-html5-20141028/


This Version:
http://www.w3.org/TR/2014/REC-html5-20141028/

Latest Published Version:
http://www.w3.org/TR/html5/

Latest Version of HTML:
http://www.w3.org/TR/html/

Latest Editor's Draft of HTML:
http://www.w3.org/html/wg/drafts/html/master/

Previous Version:
http://www.w3.org/TR/2014/PR-html5-20140916/

Previous Recommendation:
http://www.w3.org/TR/1999/REC-html401-19991224/


We would not need Previous Recommendation.  But we could use Latest Version of EME and Latest Editor’s Draft of EME to point to most current WD or later of EME and its associated Editor’s Draft.

> I'd also caution against prematurely defining a “V2” before we have a clearer idea of how VNext will be developed.

I recognize this concern but we need a path forward to create the issue and PR that I requested when I started this thread:
> I believe we have consensus to remove persistent-usage-record from EME V1 and would like to suggest we get started on this effort by a) creating an appropriate issue and then b) developing the needed pull request to make this change.

I think the plan that Mark and Philippe both agreed to is reasonable and it does not actually prejudice any V2 decisions.

/paulc


From: David Dorwin [mailto:ddorwin@google.com]
Sent: Thursday, October 27, 2016 12:12 PM
To: Philippe Le Hégaret <plh@w3.org>
Cc: Mark Watson <watsonm@netflix.com>; Paul Cotton <Paul.Cotton@microsoft.com>; Jerry Smith (WPT) <jdsmith@microsoft.com>; public-hme-editors@w3.org
Subject: Re: Removing EME persistent-usage-record "at risk" feature



On Thu, Oct 27, 2016 at 9:06 AM, Philippe Le Hégaret <plh@w3.org<mailto:plh@w3.org>> wrote:


On 10/27/2016 11:54 AM, Mark Watson wrote:
On Oct 27, 2016, at 5:14 AM, Philippe Le Hégaret <plh@w3.org<mailto:plh@w3.org>> wrote:
On 10/26/2016 9:10 PM, Mark Watson wrote:
My question, though, is whether EME V2 should take the form of a
completely new version of the specification that would (eventually)
replace the existing one​, or whether we should have a stand-alone
specification adding the "persistent-usage-record" session type. The
latter is hard to do without monkey-patching unless we introduce
explicit extension points.

Hi Mark,

here is what I would recommend we do:

We don't touch the gh-pages branch. Instead, we create a V1 branch for
now and use that one to remove whatever we need to.

Ok, so in this case the Editor's Draft at the normal
ED github link will still contain the feature and I suppose becomes
(de facto, but not officially) an ED of V2.

This is ok for me.

correct.

I think we should keep the gh-pages branch synced to V1 until we figure out a plan for VNext. The TR/ version, code, etc. reference this, and it is the latest version of the REC-track spec. While it's not clear to me whether we can make Type 3 changes (from your other email) in GitHub (but not in TR/), if we were to, I would think they would be made in gh-pages. I'd also caution against prematurely defining a “V2” before we have a clearer idea of how VNext will be developed.

If folks want to
publish a separate Note for the removed feature, there will always be
time to remove the feature from the gh-pages branch later on.

My hope is that the removed feature is standardized at a later time,
since I do not expect it will be that long before there are compliant
implementations (perhaps early next year).

Understood.

Specific to persistent-usage-record or any other removed feature, forks can always reference earlier commits, including reverting the PR that removed them. For now, I recommend maintaining a fork that contains a revert of the removal. That will allow development of that/those feature(s) to continue without worrying about process (i.e. Type 3 changes), and as a fork, it can always be merged in at the appropriate time.


Philippe

Received on Sunday, 30 October 2016 00:14:46 UTC