PSA: publishing new WD of URL spec
On Thursday, September 11, 2014, Robin Berjon ro...@w3.org javascript:_e(%7B%7D,'cvml','ro...@w3.org'); wrote: On 10/09/2014 18:48 , Marcos Caceres wrote: This is a formal objection to publication of this specification. The rationale for the objection was already sent to the wwwprocess list. Would you lift yours if Domenic lifted his? Only once I have clear answers to the following (and see actual proof). I know you already addressed some of this in your previous email to Dominic. 1. How will the spec be kept up to date? i.e., what technical means will be put in place by the w3c to assure that the latest is always on TR. 2. How will the W3C determine when a spec is ready for LC/CR? 3. How will the W3C cope with changes occurring to the living document after CR? (See Boris' emails) 4. Will the W3C prevent search engines from finding the copy/pasted document? Particularly any static snapshots. 5. What indicators (e.g., the big red box) will be put into the spec to indicate that the WHATWG version is the canonical version? 6. Out of respect for both the Editor and the WHATWG as a standards consortium, how will the W3C attribute authorship of the documents and well as show that the document originates from the WHATWG? (Ps: Your claim about 12 step programs have been debunked by science. See [1] :)) [1] http://www.npr.org/2014/03/23/291405829/with-sobering-science-doctor-debunks-12-step-recovery
Re: PSA: publishing new WD of URL spec
Hi Marcos, On 11/09/2014 17:19 , Marcos Caceres wrote: Only once I have clear answers to the following (and see actual proof). I know you already addressed some of this in your previous email to Dominic. I will address your points below, but I will repeat what I told Domenic: I don't think progress can be made by talking about stuff in the abstract. I believe in iterated progress. To put it differently, I think this should be a living commitment to a better relationship and not some finalised thing before any action is taken. Based on that I would like to get, and I think it is quite reasonable, agreement that we can go ahead and publish something better than what there was before (surely better than what *is* there) and iterate on that (as fast as possible) to get it all good. Makes sense? 1. How will the spec be kept up to date? i.e., what technical means will be put in place by the w3c to assure that the latest is always on TR. As announced on spec-prod and discussed with CSS recently, Philippe has been working on an automated publisher. My understanding is that he hopes to have a prototype by TPAC, and to ship in early 2015 (likely with some guinea pigs having earlier access). Please provide input to that project (in its own thread). 2. How will the W3C determine when a spec is ready for LC/CR? Is there any reason to use anything other than tests + implementations? 3. How will the W3C cope with changes occurring to the living document after CR? (See Boris' emails) I have been advocating a software model for specs for so long that you're probably tired of hearing it; but I think we can apply the release/development branching here. 4. Will the W3C prevent search engines from finding the copy/pasted document? Particularly any static snapshots. Why would you restrict that to imported snapshots? We're looking at blanket-preventing that for dated TR; anyone can add meta robots noindex to TR drafts. I'm certainly happy to do that for URL, DOM, and likely a bunch of others when they next get published. 5. What indicators (e.g., the big red box) will be put into the spec to indicate that the WHATWG version is the canonical version? Do you want something better than the big red box? 6. Out of respect for both the Editor and the WHATWG as a standards consortium, how will the W3C attribute authorship of the documents and well as show that the document originates from the WHATWG? So what's been done for DOM and URL has been to just list those editors. I'd be happy to remove the snapshotting editors but I think that's not possible *yet* if the original authors aren't on the WG. Apart from that, it should be included in the SotD and in the big red box. So? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: PSA: publishing new WD of URL spec
On 2014-09-11 17:19, Marcos Caceres wrote: ... 5. What indicators (e.g., the big red box) will be put into the spec to indicate that the WHATWG version is the canonical version? ... It's my understanding that the intent is to actually make technical changes, as indicated in: This specification documents current RFC 3986 and RFC 3987 handling in contemporary Web browser implementations. As a consequence, this specification is not compatible with those RFCs. It is published for the purpose of providing a stable reference for the HTML5 specification and reflecting current Web browser HTML5 implementations. The W3C Technical Architecture Group expects to continue the work on the URL specification and produce a future version that will attempt to re-align the URL specification with an updated version of RFC 3986 while preserving interoperability. In which case the WHATWG version wouldn't be canonical anymore anyway. Best regards, Julian
Re: PSA: publishing new WD of URL spec
On Thu, Sep 11, 2014 at 5:58 PM, Julian Reschke julian.resc...@greenbytes.de wrote: It's my understanding that the intent is to actually make technical changes, as indicated in: This specification documents current RFC 3986 and RFC 3987 handling in contemporary Web browser implementations. As a consequence, this specification is not compatible with those RFCs. It is published for the purpose of providing a stable reference for the HTML5 specification and reflecting current Web browser HTML5 implementations. The W3C Technical Architecture Group expects to continue the work on the URL specification and produce a future version that will attempt to re-align the URL specification with an updated version of RFC 3986 while preserving interoperability. In which case the WHATWG version wouldn't be canonical anymore anyway. It would be for implementers. Seems ill-advised to implement something that contains contradictory goals and is bound to be incompatible with deployed content. -- http://annevankesteren.nl/
Re: PSA: publishing new WD of URL spec
On Thu, Sep 11, 2014 at 12:13 PM, Anne van Kesteren ann...@annevk.nl wrote: In which case the WHATWG version wouldn't be canonical anymore anyway. It would be for implementers. Only those implementers that can afford to staff a team to keep up with a moving target. That's not all potential implementers.
Re: PSA: publishing new WD of URL spec
On Thu, Sep 11, 2014 at 6:52 PM, Mark Baker dist...@acm.org wrote: Only those implementers that can afford to staff a team to keep up with a moving target. That's not all potential implementers. What do you mean moving target? In general we only change specifications if there's something wrong or if there is a new feature the community would like to add. Living Standard does not mean core algorithms are constantly changing. It just means they are maintained, as all software has to be. -- http://annevankesteren.nl/
Re: PSA: publishing new WD of URL spec
On 9/11/14, 12:52 PM, Mark Baker wrote: On Thu, Sep 11, 2014 at 12:13 PM, Anne van Kesteren ann...@annevk.nl wrote: In which case the WHATWG version wouldn't be canonical anymore anyway. It would be for implementers. Only those implementers that can afford to staff a team to keep up with a moving target. That's not all potential implementers. Mark, the options are to have a team do that or to have a team to reverse-engineer the other implementations. Assuming you want to be interoperable with said implementations, of course. Tracking a well-written spec is _usually_ simpler than reverse-engineering other implementations... -Boris
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: PSA: publishing new WD of URL spec
On Wed, Sep 10, 2014 at 6:39 PM, Arthur Barstow art.bars...@gmail.com wrote: 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/ What about the comments raised so far, e.g.: http://lists.w3.org/Archives/Public/www-tag/2014Aug/0100.html -- http://annevankesteren.nl/
Re: PSA: publishing new WD of URL spec
On September 10, 2014 at 12:43:02 PM, Arthur Barstow (art.bars...@gmail.com) wrote: [ 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. This is a formal objection to publication of this specification. The rationale for the objection was already sent to the wwwprocess list.
