Re: URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec)
TL;DR: Administrative details from the W3C Webapps cochair responsible for URL in that group. Relevant in practice is a request to minimise channels of communication to simplify spec archaeology, and especially to prefer public-webapps over www-archive, but I don't see there is any reason this WorkMode cannot be used. 02.12.2014, 04:19, Sam Ruby ru...@intertwingly.net: On 11/18/2014 03:18 PM, Sam Ruby wrote: Meanwhile, I'm working to integrate the following first into the WHATWG version of the spec, and then through the WebApps process: http://intertwingly.net/projects/pegurl/url.html Integration is proceeding, current results can be seen here: https://specs.webplatform.org/url/webspecs/develop/ It is no longer clear to me what through the WebApps process means. In an attempt to help define such, I'm making a proposal: https://github.com/webspecs/url/blob/develop/docs/workmode.md#preface At this point, I'm looking for general feedback. I'm particularly interested in things I may have missed. A bunch of comments about how to work with a W3C group: Participation and Communication… In W3C there is a general desire to track contributions, and ensure that contributors have made patent commitments. When discussion is managed through the W3C working group, the chairs and staff contact take responsibility for this, in conjunction with editors. If the editor wants to use other sources, then we ask the editor to take responsibility for tracking those sources. The normal approach is to request that contributors join the Working Group, either as invited experts or because they represent a member organisation. In many cases, contributors are already represented in webapps - for instance while Anne van Kesteren isn't personally a member, his employer is, and there is therefore a commitment from them. While webapps generally prefers conversations to be on the webapps list (because it makes it easier to do the archaeology in a decade or so if someone needs to), there is no formal ban on using other sources. However, I would ask that you request comments on publicly archived lists, and specifically that you strongly prefer public-webapps@w3.org (which is a list designated for technical discussion whose subscribers include W3C members who expect to discuss work items in the scope of the webapps group, such as the URL spec) to www-archive (which is just a place to give a public anchor to random email - the subscription list is completely random and likely not to include many interested W3C members). The TR Process… The WHATWG document is not a Public Working Draft in the sense of the W3C Process (which has implications for e.g. patent policy). Regularly publishing a Public Working Draft to w3.org/TR is part of what makes the patent policy work, since commitments are bound to various stages including the latest Public Working Draft (i.e. TR version, not editors' draft) before someone left the group [wds]. Those snapshots are required to be hosted by W3C and to meet the team's requirements, as determined by the Team from time to time. If there is an issue there, let's deal with it when we see it. Webapps still generally works under the 2005 version of the Process - but we could change this document to the 2014 process. The only really noticeable difference will be that there is formally no Last Call, and the final Patent Exclusion opportunity is instead for the draft published as Candidate Recommendation. (In other words, you need to be pretty bureaucratically-minded to notice a difference). Documents published by W3C are published under whatever license W3C decides. The Webapps charter explicitly calls out the URL spec for publishing under the CC-BY license [chart], so that is what I would expect for all snapshots. For normative references, at least until Last Call or CR (depending on whether you use the modern Process) I don't think we need to care a huge amount. When we do get there, the policy for publishing at W3C will determine what we can do in a W3C publication - although we should note that there is a lot of discussion about references that fails to take reality into account,and many specs have normative references that are actually unusable normatively. My *personal* sense is that a lot more references should be informative, admitting the state of the universe as it is rather than as we wish it were. But I'm inclined to cross that when we get there. Editors Editors of W3C specs are required [eds] to be members of the Working Group publishing the spec. Webapps is pretty liberal about appointing editors - the principal criteria are you are in the group and volunteer to do work. Patent Policy As I read the invited expert agreement [iea] it uses branching (quoted - french-style) as an example of creating derivative works that include the Invited Expert's contributions when those derivative works are likely to cause confusion about the
URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec)
On 11/18/2014 03:18 PM, Sam Ruby wrote: Meanwhile, I'm working to integrate the following first into the WHATWG version of the spec, and then through the WebApps process: http://intertwingly.net/projects/pegurl/url.html Integration is proceeding, current results can be seen here: https://specs.webplatform.org/url/webspecs/develop/ It is no longer clear to me what through the WebApps process means. In an attempt to help define such, I'm making a proposal: https://github.com/webspecs/url/blob/develop/docs/workmode.md#preface At this point, I'm looking for general feedback. I'm particularly interested in things I may have missed. Pull requests welcome! Once discussion dies down, I'll try go get agreement between the URL editors, the WebApps co-chairs and W3C Legal. If/when that is complete, this will go to W3C Management and whatever the WHATWG equivalent would be. - Sam Ruby
Re: URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec)
Just in case I haven't formally said this elsewhere: My personal feeling is that it's probably better to stay away from speccing the behavior of file:// URLs. There's very little incentive for browsers to align on how to handle file:// handling. The complexities of different file system behaviors on different platforms and different file system backends makes doing comprehensive regression testing painful. And the value is pretty low because there's almost no browser content that uses absolute file:// URLs. I'm not sure if non-browser URL consuming software has different incentives. Most software that loads resources from the local file system use file paths, rather than file:// URLs. Though I'm sure there are exceptions. And it seems like file:// URLs add a significant chunk of complexity to the spec. Complexity which might be for naught if implementations don't implement them. / Jonas On Mon, Dec 1, 2014 at 5:17 PM, Sam Ruby ru...@intertwingly.net wrote: On 11/18/2014 03:18 PM, Sam Ruby wrote: Meanwhile, I'm working to integrate the following first into the WHATWG version of the spec, and then through the WebApps process: http://intertwingly.net/projects/pegurl/url.html Integration is proceeding, current results can be seen here: https://specs.webplatform.org/url/webspecs/develop/ It is no longer clear to me what through the WebApps process means. In an attempt to help define such, I'm making a proposal: https://github.com/webspecs/url/blob/develop/docs/workmode.md#preface At this point, I'm looking for general feedback. I'm particularly interested in things I may have missed. Pull requests welcome! Once discussion dies down, I'll try go get agreement between the URL editors, the WebApps co-chairs and W3C Legal. If/when that is complete, this will go to W3C Management and whatever the WHATWG equivalent would be. - Sam Ruby
RE: URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec)
What we really need to do is get some popular library or website to take a dependency on mobile Chrome or mobile Safari's file URL parsing. *Then* we'd get interoperability, and quite quickly I'd imagine. From: Jonas Sickingmailto:jo...@sicking.cc Sent: 2014-12-01 22:07 To: Sam Rubymailto:ru...@intertwingly.net Cc: Webapps WGmailto:public-webapps@w3.org Subject: Re: URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec) Just in case I haven't formally said this elsewhere: My personal feeling is that it's probably better to stay away from speccing the behavior of file:// URLs. There's very little incentive for browsers to align on how to handle file:// handling. The complexities of different file system behaviors on different platforms and different file system backends makes doing comprehensive regression testing painful. And the value is pretty low because there's almost no browser content that uses absolute file:// URLs. I'm not sure if non-browser URL consuming software has different incentives. Most software that loads resources from the local file system use file paths, rather than file:// URLs. Though I'm sure there are exceptions. And it seems like file:// URLs add a significant chunk of complexity to the spec. Complexity which might be for naught if implementations don't implement them. / Jonas On Mon, Dec 1, 2014 at 5:17 PM, Sam Ruby ru...@intertwingly.net wrote: On 11/18/2014 03:18 PM, Sam Ruby wrote: Meanwhile, I'm working to integrate the following first into the WHATWG version of the spec, and then through the WebApps process: http://intertwingly.net/projects/pegurl/url.html Integration is proceeding, current results can be seen here: https://specs.webplatform.org/url/webspecs/develop/ It is no longer clear to me what through the WebApps process means. In an attempt to help define such, I'm making a proposal: https://github.com/webspecs/url/blob/develop/docs/workmode.md#preface At this point, I'm looking for general feedback. I'm particularly interested in things I may have missed. Pull requests welcome! Once discussion dies down, I'll try go get agreement between the URL editors, the WebApps co-chairs and W3C Legal. If/when that is complete, this will go to W3C Management and whatever the WHATWG equivalent would be. - Sam Ruby
Re: URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec)
On Mon, Dec 1, 2014 at 7:11 PM, Domenic Denicola d...@domenic.me wrote: What we really need to do is get some popular library or website to take a dependency on mobile Chrome or mobile Safari's file URL parsing. *Then* we'd get interoperability, and quite quickly I'd imagine. To my knowledge, all browsers explicitly block websites from having any interactions with file:// URLs. I.e. they don't allow loading an img from file:// or even link to a file:// HTML page using a href=file:// Even though both those are generally allowed cross origin. So it's very difficult for webpages to depend on the behavior of file:// parsing, even if they were to intentionally try. / Jonas From: Jonas Sicking Sent: 2014-12-01 22:07 To: Sam Ruby Cc: Webapps WG Subject: Re: URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec) Just in case I haven't formally said this elsewhere: My personal feeling is that it's probably better to stay away from speccing the behavior of file:// URLs. There's very little incentive for browsers to align on how to handle file:// handling. The complexities of different file system behaviors on different platforms and different file system backends makes doing comprehensive regression testing painful. And the value is pretty low because there's almost no browser content that uses absolute file:// URLs. I'm not sure if non-browser URL consuming software has different incentives. Most software that loads resources from the local file system use file paths, rather than file:// URLs. Though I'm sure there are exceptions. And it seems like file:// URLs add a significant chunk of complexity to the spec. Complexity which might be for naught if implementations don't implement them. / Jonas On Mon, Dec 1, 2014 at 5:17 PM, Sam Ruby ru...@intertwingly.net wrote: On 11/18/2014 03:18 PM, Sam Ruby wrote: Meanwhile, I'm working to integrate the following first into the WHATWG version of the spec, and then through the WebApps process: http://intertwingly.net/projects/pegurl/url.html Integration is proceeding, current results can be seen here: https://specs.webplatform.org/url/webspecs/develop/ It is no longer clear to me what through the WebApps process means. In an attempt to help define such, I'm making a proposal: https://github.com/webspecs/url/blob/develop/docs/workmode.md#preface At this point, I'm looking for general feedback. I'm particularly interested in things I may have missed. Pull requests welcome! Once discussion dies down, I'll try go get agreement between the URL editors, the WebApps co-chairs and W3C Legal. If/when that is complete, this will go to W3C Management and whatever the WHATWG equivalent would be. - Sam Ruby
