Re: publishing new WD of URL spec
On Thu, Sep 11, 2014 at 2:20 PM, Robin Berjon ro...@w3.org 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
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: http://w3ctag.github.io/url/ 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] http://www.w3.org/2014/06/webapps-charter.html#liaisons [OffTopic] https://www.w3.org/2008/webapps/wiki/WorkMode#Off-Topic_Discussion_Policy [w3process] http://lists.w3.org/Archives/Public/public-w3process/
Re: publishing new WD of URL spec
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: http://w3ctag.github.io/url/ 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]
Re: publishing new WD of URL spec
On Wed, Sep 10, 2014 at 3:14 PM, Glenn Adams 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
On Thu, Sep 11, 2014 at 12:27 AM, James Robinson jam...@google.com wrote: On Wed, Sep 10, 2014 at 3:14 PM, Glenn Adams gl...@skynav.com 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
(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 gl...@skynav.com wrote: On Thu, Sep 11, 2014 at 12:27 AM, James Robinson jam...@google.com wrote: On Wed, Sep 10, 2014 at 3:14 PM, Glenn Adams gl...@skynav.com 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
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
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 INPUT TYPE=file 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 bzbar...@mit.edu 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
