Re: publishing new WD of URL spec

[Glenn Adams]

On Thu, Sep 11, 2014 at 2:20 PM, Robin Berjon  wrote:

> On 11/09/2014 00:14 , Glenn Adams wrote:
>
>> WHATWG specs are not legitimate for reference by W3C specs. Their IPR
>> status is indeterminate and they do not follow a consensus process.
>>
>
> This is blatant trolling as well as factually wrong in every single
> statement that it makes.
>

I would say something impolite and vulgar at this point. But you've already
pulled down this thread to the gutter Robin by resorting to name calling,
so I won't do that.


>
> I would invite all of you to not feed this thread as it can't possibly
> lead anywhere useful.


You mean, don't feed it like you are doing?

As a W3T member, I would think it your duty to stay out of the fray. Best
listen to your duty.


>
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>

Re: publishing new WD of URL spec

[Robin Berjon]

Hi Domenic,

I agree with everything that you have said.

I would like to follow your lead in offering a way forward towards a 
resolution here.


Before I dive into the details, however, I would like to offer a mode of 
work. We can talk and talk and talk about the details until we're all 
blue in the face, but if it's only talking we'll likely run out of 
energy and hit walls because, let's face it, talking about this stuff 
isn't all that interesting.


Instead, I would like for us to work on reaching that amicable situation 
by doing things. That means that instead of freezing everything we ship 
a WD that may not be perfect but improves things, and we do that again, 
and again (and to EDs too where needed) until we're all happy.


Does that sound like a plan?

On 10/09/2014 23:58 , Domenic Denicola wrote:

My arguments against publishing this specification include that
copying the spec from the WHATWG is an unnecessarily combative way of
working with another standards body, especially with regard to the
URL Standard wherein we/they have been trying hard to address the
issues of IP coverage and stable references on the W3C's terms. I
would rather see this talked through and agreement come to regarding
how the W3C can work to reference WHATWG specs in the same way that
they reference Ecma or IETF specs.


I agree entirely. I would be happy to be able to reference WHATWG 
specifications, and I think we can get there.


People cite issues with doing that, but I do not believe that they stand 
up to careful examination.


The patent issue is of concern, but it is not without solutions.

The claim that WHATWG doesn't follow a consensus model is simply not 
true (despite what the WHATWG wiki says about that). There are 
exceptions and violations, but overall I see a lot of consensus going on 
there. That's certainly the case for the likes of URL, DOM, Streams...


The bigger part of the problem is social. There is a lot of invidious 
history. We can get to a point at which we get better IP commitments but 
that requires people to act in a collaborative manner.



On the technical side, I argue that previous efforts to copy WHATWG
specs, even well-intentioned ones like the DOM, have led to
out-of-date snapshots permeating the internet, and causing developer
and implementer confusion. (See links in [1]; see also the contrast
between one implementer's policies at [2] and another's at [3].) We
can't even fall back to "never look at TR because it is always out of
date; use ED instead!" because in the case of e.g. DOM "4", the ED is
five months out of date.


Here is my proposal to fix that for URL (and if we agree, I'll fix it 
for DOM too):


  - Remove the ED by using any branch other than gh-pages. No ones 
needs that anyway.


  - Include  to the TR snapshots.

  - Include a very visible warning in the TR snapshot telling people to 
go to the (real) ED.


I would like to get to a point where we can just reference WHATWG specs 
(it would certainly make my life much easier), but while we figure out a 
way of making TR snapshots roughly functional I'd like to try that now 
(if only so we can get a feel for snapshotting properly).


I *think* that the above proposals, which are implementable right away, 
address your concerns. WDYT?


In addition to the above I would like, as we might have to stick with 
the TR snapshotting for a little while until we figure out a better way, 
to include WHATWG co-branding on the TR version. I can't commit to doing 
that immediately as it's something I need buy-in for, but there's 
precedent (http://www.w3.org/TR/2010/REC-webcgm21-20100301/).



I acknowledge that Dan is going to great lengths to make sure that
this copying is done "right", insofar as it can be. E.g., he is
copying not plagiarizing; he is stating that he wants feedback to
flow through the upstream version instead of diverging; and he says
that he will add more clear signposting to the document to help
direct implementers and developers to the upstream version. However,
I think this plan is merely a band-aid on a larger problem, akin to
feeding the W3C's spec-copying addiction with a nicotine patch
instead of a full-on cancer stick. An improvement, but I'd really
prefer we break the addiction entirely.


Agreed, but to thread your metaphor there's a reason you have 12-step 
programmes and going cold turkey is considered a bad idea (in fact it 
can be fatal in some addictions). I say let's do this in an n-steps way.



There are a number of remedies that would address this formal
objection. The most preferable would be for the W3C to work amicably
with the WHATWG to figure out a way to treat them and their specs as
legitimate, instead of constantly copying them.


+1. I would like that discussion to:

  - be in public
  - not be on a technical list
  - not be on a generic process list (because it should be focused)
  - be strict about banning trolls

If you agree that's something we ought to do, I'm happy to set u

Re: publishing new WD of URL spec

[Robin Berjon]

On 11/09/2014 00:14 , Glenn Adams wrote:

WHATWG specs are not legitimate for reference by W3C specs. Their IPR
status is indeterminate and they do not follow a consensus process.


This is blatant trolling as well as factually wrong in every single 
statement that it makes.


I would invite all of you to not feed this thread as it can't possibly 
lead anywhere useful.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: publishing new WD of URL spec

[James Salsman]

It could be worse! After 15 years and a handful of vendor
implementations over the years, neither W3C nor WHATWG have simple
microphone upload in  forms. There's
http://dev.w3.org/2009/dap/camera/ of course, which has been almost
there since around 2007, but still doesn't say what "capture control
type" to use for, e.g., the open source speex vocoder. At this point I
have so much Stockholm syndrome that I'm actually enjoying the show.
But I weep for what future historians of technology will have to go
through to come to terms with it all.


On Wed, Sep 10, 2014 at 3:44 PM, Boris Zbarsky  wrote:
> On 9/10/14, 6:14 PM, Glenn Adams wrote:
>>
>> and they do not follow a consensus process.
>
>
> Glenn, with all due respect, neither do many W3C specifications.  Case in
> point is http://www.w3.org/TR/navigation-timing/ which managed to get to REC
> while ignoring feedback that pointed out that not a single implementation
> actually matched the specification (including the ones produced by the
> employers of the editors).  And this wasn't because the implementations were
> buggy, but because the specification was incomplete.
>
> Of course now that it's a REC getting it fixed is a major production; given
> that it didn't happen back when it should have I have no hope of it
> happening now.
>
> This is hardly an isolated incident with W3C specifications.  In fact, and
> very unfortunately, it's the most common thing I see happening.
>
> -Boris
>

Re: publishing new WD of URL spec

[Boris Zbarsky]

On 9/10/14, 6:14 PM, Glenn Adams wrote:

and they do not follow a consensus process.


Glenn, with all due respect, neither do many W3C specifications.  Case 
in point is http://www.w3.org/TR/navigation-timing/ which managed to get 
to REC while ignoring feedback that pointed out that not a single 
implementation actually matched the specification (including the ones 
produced by the employers of the editors).  And this wasn't because the 
implementations were buggy, but because the specification was incomplete.


Of course now that it's a REC getting it fixed is a major production; 
given that it didn't happen back when it should have I have no hope of 
it happening now.


This is hardly an isolated incident with W3C specifications.  In fact, 
and very unfortunately, it's the most common thing I see happening.


-Boris

Re: publishing new WD of URL spec

[James Robinson]

(public-webapps and www-tag to bcc, +cc public-w3cproc...@w3.org.  sorry
about the earlier mistake)

On Wed, Sep 10, 2014 at 4:26 PM, Glenn Adams  wrote:

>
> On Thu, Sep 11, 2014 at 12:27 AM, James Robinson 
> wrote:
>
>> On Wed, Sep 10, 2014 at 3:14 PM, Glenn Adams  wrote:
>>
>>> WHATWG specs are not legitimate for reference by W3C specs.
>>>
>>
>> Do you have a citation to back up this claim?
>>
>
> If it isn't obvious, I am stating my opinion regarding the matter of
> legitimacy. Just like Domenic is stating his opinion. My opinion is based
> on 20 years of experience with the W3C and 40 years of experience with
> standards bodies.
>

OK, so it's just your opinion.


>
> The current W3C normative references guidelines [1], only recently
> published, are the only written policy of which I'm aware. This document
> does not prohibit referencing a WHATWG document.
>

>
...

>
> I agree, but that doesn't mean that it is acceptable or even a good idea
> to permit normative references to a WHATWG "work", i.e., a work of Hixie
> and friends.
>

I wasn't asking what your opinion was, I was asking what W3C policy was.
 The answer appears to be that what you originally posted is not accurate
at all and you were simply stating what you wished policy was.  Thank you
for clarifying.

- James

Re: publishing new WD of URL spec

[Glenn Adams]

On Thu, Sep 11, 2014 at 12:27 AM, James Robinson  wrote:

> On Wed, Sep 10, 2014 at 3:14 PM, Glenn Adams  wrote:
>
>> WHATWG specs are not legitimate for reference by W3C specs.
>>
>
> Do you have a citation to back up this claim?
>

If it isn't obvious, I am stating my opinion regarding the matter of
legitimacy. Just like Domenic is stating his opinion. My opinion is based
on 20 years of experience with the W3C and 40 years of experience with
standards bodies.

In contrast, my claim regarding IPR policy and lack of consensus is not an
opinion, but an uncontested fact. Or would you dispute this?


>
>
>> Their IPR status is indeterminate and they do not follow a consensus
>> process.
>>
>
> Do you have citations for where this is listed as part of the requirements
> for references in W3C specifications?
>

The current W3C normative references guidelines [1], only recently
published, are the only written policy of which I'm aware. This document
does not prohibit referencing a WHATWG document. Ultimately, only TBL (or
his delegate) will make a decision on such matters. But I trust they will
take input from their members into account.

Reading [1], one wonders how the WHATWG would fare on the question of
"Stability of the Referenced Document", including "Stability of the
Organization/Group". Since there is no organization per se, and since the
philosophy of the WHATWG is explicitly contrasted with the notion of
"stability", then there are serious questions to be asked about permitting
such a reference.

[1] http://www.w3.org/2013/09/normative-references


>
> I know these are your personal opinions but am not aware of anything that
> states this is W3C process.
>

I agree, but that doesn't mean that it is acceptable or even a good idea to
permit normative references to a WHATWG "work", i.e., a work of Hixie and
friends. Personally, I don't care how good the technical content of this
work is if its authors refuse to participate in accepted processes. Why,
for instance, is this work [URL] not being taken to the IETF? That is the
natural home for such work. From all appearance, the answer is that Hixie
et al don't like playing the normally accepted standards process game and
wish to sideline it for their own ends. While I admire Hixie and his group
of friends for their technical proclivity, I do not admire their refusal to
work within accepted practices.

There is good value in following the W3C IPR policies and participating in
a consensus process. So I object to efforts that would diminish or
destabilize the value proposition of the W3C, the IETF, and other accepted
organizations, for no other apparent purpose than to satisfy the whim and
impatience of a gang of Young Turks.

I think this is all I need to say on this subject, so I will avoid
continuing this thread. Take it as you will.



>
> - James
>

RE: publishing new WD of URL spec

[Domenic Denicola]

[public-webapps and www-tag to bcc]

Hi Glenn, James,

I think as Art carefully reminded us, this is off-topic for www-tag and 
public-webapps. I hope you will contain further discussions to public-w3process 
as was requested.

From: James Robinson [mailto:jam...@google.com]
Sent: Thursday, September 11, 2014 00:28
To: Glenn Adams
Cc: Domenic Denicola; Arthur Barstow; public-webapps; www-...@w3.org
Subject: Re: publishing new WD of URL spec

On Wed, Sep 10, 2014 at 3:14 PM, Glenn Adams 
mailto:gl...@skynav.com>> wrote:
WHATWG specs are not legitimate for reference by W3C specs.

Do you have a citation to back up this claim?

Their IPR status is indeterminate and they do not follow a consensus process.

Do you have citations for where this is listed as part of the requirements for 
references in W3C specifications?

I know these are your personal opinions but am not aware of anything that 
states this is W3C process.

- James

Re: publishing new WD of URL spec

[James Robinson]

On Wed, Sep 10, 2014 at 3:14 PM, Glenn Adams  wrote:

> WHATWG specs are not legitimate for reference by W3C specs.
>

Do you have a citation to back up this claim?


> Their IPR status is indeterminate and they do not follow a consensus
> process.
>

Do you have citations for where this is listed as part of the requirements
for references in W3C specifications?

I know these are your personal opinions but am not aware of anything that
states this is W3C process.

- James

Re: publishing new WD of URL spec

[Glenn Adams]

WHATWG specs are not legitimate for reference by W3C specs. Their IPR
status is indeterminate and they do not follow a consensus process.

On Wed, Sep 10, 2014 at 11:58 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> This is a formal objection to the publication of this specification.
>
> My arguments against publishing this specification include that copying
> the spec from the WHATWG is an unnecessarily combative way of working with
> another standards body, especially with regard to the URL Standard wherein
> we/they have been trying hard to address the issues of IP coverage and
> stable references on the W3C's terms. I would rather see this talked
> through and agreement come to regarding how the W3C can work to reference
> WHATWG specs in the same way that they reference Ecma or IETF specs.
>
> On the technical side, I argue that previous efforts to copy WHATWG specs,
> even well-intentioned ones like the DOM, have led to out-of-date snapshots
> permeating the internet, and causing developer and implementer confusion.
> (See links in [1]; see also the contrast between one implementer's policies
> at [2] and another's at [3].) We can't even fall back to "never look at TR
> because it is always out of date; use ED instead!" because in the case of
> e.g. DOM "4", the ED is five months out of date.
>
> I acknowledge that Dan is going to great lengths to make sure that this
> copying is done "right", insofar as it can be. E.g., he is copying not
> plagiarizing; he is stating that he wants feedback to flow through the
> upstream version instead of diverging; and he says that he will add more
> clear signposting to the document to help direct implementers and
> developers to the upstream version. However, I think this plan is merely a
> band-aid on a larger problem, akin to feeding the W3C's spec-copying
> addiction with a nicotine patch instead of a full-on cancer stick. An
> improvement, but I'd really prefer we break the addiction entirely.
>
> There are a number of remedies that would address this formal objection.
> The most preferable would be for the W3C to work amicably with the WHATWG
> to figure out a way to treat them and their specs as legitimate, instead of
> constantly copying them. This could include e.g. issuing a call to the AC
> reps in the webapps working group to commit to patent protection via the
> WHATWG's patent mechanism [4]. In the category of "these proposals MAY be
> vague or incomplete" [5], I would like the W3C to consider seriously how to
> react to the world wherein standards best serve the web by being living,
> and find some way to get out of the outmoded and bug-encouraging mode of
> thinking that stands behind "stable references."
>
> An alternate way of addressing the formal objection would be outline a
> very clear process for avoiding the dangers that have cropped up in
> previous WHATWG copies. This would include, among other things: an
> automated system for ensuring that the latest version of the upstream spec
> is always copied to TR; a blacklisting of outdated snapshots from search
> engines via robots.txt; some way of dealing with the fact that webapps
> patent commitments will be made to an outdated snapshot, but that snapshot
> should not be given any prominence for implementers or authors visiting the
> W3C website; and a public acknowledgement that implementers should not look
> at any outdated snapshots such as CR (so, the normal "call for
> implementations" would have to be modified, so we don't get ridiculous
> situations like HTML 5.0 is currently undergoing where you call for
> implementations of a spec that is multiple years behind what
> implementations actually need to implement for interoperability).
>
> [1]: http://wiki.whatwg.org/wiki/TR_strikes_again
> [2]: https://github.com/mozilla/servo/wiki/Relevant-spec-links
> [3]: http://status.modern.ie/
> [4]: http://blog.whatwg.org/make-patent-commitments
> [5]: http://www.w3.org/2014/Process-20140801/#FormalObjection
>
>
> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@gmail.com]
> Sent: Wednesday, September 10, 2014 18:40
> To: public-webapps; www-...@w3.org
> Subject: PSA: publishing new WD of URL spec
>
> [ Sorry for the cross-posting but this is about a joint WD publication
> between WebApps and TAG. ]
>
> This is heads-up (aka PublicServiceAnnoucement) about the intent to
> publish a new WD of the URL spec (on or around Sept 16) using this ED as
> the basis:
>
>
>
> As previously agree, and codified in WebApps' current [Charter], the WD
> will be published jointly by WebApps and the TAG.
>
> I realize some people do not support W3C publishing the URL spec, so as
> reminder - as defined in WebApps' off-topic discussion policy
> ([OffTopic]) - if anyone has any _process-type_ comments, concerns, etc.
> about this publication - please send that feedback to the public-w3process
> list [w3process]. Please do _not_ send such feedback t

RE: publishing new WD of URL spec

[Domenic Denicola]

This is a formal objection to the publication of this specification.

My arguments against publishing this specification include that copying the 
spec from the WHATWG is an unnecessarily combative way of working with another 
standards body, especially with regard to the URL Standard wherein we/they have 
been trying hard to address the issues of IP coverage and stable references on 
the W3C's terms. I would rather see this talked through and agreement come to 
regarding how the W3C can work to reference WHATWG specs in the same way that 
they reference Ecma or IETF specs.

On the technical side, I argue that previous efforts to copy WHATWG specs, even 
well-intentioned ones like the DOM, have led to out-of-date snapshots 
permeating the internet, and causing developer and implementer confusion. (See 
links in [1]; see also the contrast between one implementer's policies at [2] 
and another's at [3].) We can't even fall back to "never look at TR because it 
is always out of date; use ED instead!" because in the case of e.g. DOM "4", 
the ED is five months out of date.

I acknowledge that Dan is going to great lengths to make sure that this copying 
is done "right", insofar as it can be. E.g., he is copying not plagiarizing; he 
is stating that he wants feedback to flow through the upstream version instead 
of diverging; and he says that he will add more clear signposting to the 
document to help direct implementers and developers to the upstream version. 
However, I think this plan is merely a band-aid on a larger problem, akin to 
feeding the W3C's spec-copying addiction with a nicotine patch instead of a 
full-on cancer stick. An improvement, but I'd really prefer we break the 
addiction entirely.

There are a number of remedies that would address this formal objection. The 
most preferable would be for the W3C to work amicably with the WHATWG to figure 
out a way to treat them and their specs as legitimate, instead of constantly 
copying them. This could include e.g. issuing a call to the AC reps in the 
webapps working group to commit to patent protection via the WHATWG's patent 
mechanism [4]. In the category of "these proposals MAY be vague or incomplete" 
[5], I would like the W3C to consider seriously how to react to the world 
wherein standards best serve the web by being living, and find some way to get 
out of the outmoded and bug-encouraging mode of thinking that stands behind 
"stable references."

An alternate way of addressing the formal objection would be outline a very 
clear process for avoiding the dangers that have cropped up in previous WHATWG 
copies. This would include, among other things: an automated system for 
ensuring that the latest version of the upstream spec is always copied to TR; a 
blacklisting of outdated snapshots from search engines via robots.txt; some way 
of dealing with the fact that webapps patent commitments will be made to an 
outdated snapshot, but that snapshot should not be given any prominence for 
implementers or authors visiting the W3C website; and a public acknowledgement 
that implementers should not look at any outdated snapshots such as CR (so, the 
normal "call for implementations" would have to be modified, so we don't get 
ridiculous situations like HTML 5.0 is currently undergoing where you call for 
implementations of a spec that is multiple years behind what implementations 
actually need to implement for interoperability).

[1]: http://wiki.whatwg.org/wiki/TR_strikes_again
[2]: https://github.com/mozilla/servo/wiki/Relevant-spec-links
[3]: http://status.modern.ie/
[4]: http://blog.whatwg.org/make-patent-commitments
[5]: http://www.w3.org/2014/Process-20140801/#FormalObjection


-Original Message-
From: Arthur Barstow [mailto:art.bars...@gmail.com] 
Sent: Wednesday, September 10, 2014 18:40
To: public-webapps; www-...@w3.org
Subject: PSA: publishing new WD of URL spec

[ Sorry for the cross-posting but this is about a joint WD publication between 
WebApps and TAG. ]

This is heads-up (aka PublicServiceAnnoucement) about the intent to publish a 
new WD of the URL spec (on or around Sept 16) using this ED as the basis:

   

As previously agree, and codified in WebApps' current [Charter], the WD will be 
published jointly by WebApps and the TAG.

I realize some people do not support W3C publishing the URL spec, so as 
reminder - as defined in WebApps' off-topic discussion policy
([OffTopic]) - if anyone has any _process-type_ comments, concerns, etc.  about 
this publication - please send that feedback to the public-w3process list 
[w3process]. Please do _not_ send such feedback to public-webapps nor www-tag.

-Thanks, AB

[Charter] 
[OffTopic]

[w3process]