- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sun, 19 May 2013 16:45:59 -0700
- To: Charles McCathie Nevile <chaals@yandex-team.ru>
- Cc: Anne van Kesteren <annevk@annevk.nl>, public-webapps WG <public-webapps@w3.org>
On Tue, May 14, 2013 at 4:24 AM, Charles McCathie Nevile <chaals@yandex-team.ru> wrote: > On Mon, 13 May 2013 17:25:23 +0100, Anne van Kesteren <annevk@annevk.nl> > wrote: >> What's wrong with the http://url.spec.whatwg.org/ URL standard. > > 1. It is apparently not intended to become a stable reference that can be > used in situations where fixing every edge case is less important than > fixing the content we agree we are looking at. As Anne noted, it's the edge cases that are *important* to resolve. We already have specs that define a bunch of the easy stuff, but they leave off the edge cases that allow interoperability. > 2. It provides extremely detailed algorithms that certain classes of tools > require to work with URLs, at the expense of an "easily-read" explanation of > what is and isn't a URL. This is the work of an Intro section, or at most an Explainer document. Either would be welcome! The URL spec accepts pull requests. ^_^ > 3. It does not provide any kind of license commitment from anyone likely to > have patents on the technology described. URLs are old enough that this is less likely to be an issue than for many techs being specified today. Regardless, though, this is something that can be solved more easily by leaning on existing W3C process - spin up a community group, occasionally copy over a snapshot of the URL spec, and publish it as a Final Specification (or whatever the name is). This gives you patent coverage, and is basically mechanical. >> Not invented here? > > Ironically (given the history of URLs as used on the Web today), that is > indeed a defensible explanation of one issue. For reasons including > stability of the document content, WHAT-WG "living standards" are not > suitable as normative references for W3C Recommendations. As you note, HTML > essentially depends on having a sound reference. (For other mostly technical > reasons I believe that RFC 3986 and perhaps to a lesser extent RFC 3987 are > not especially suitable either, because the question is equally valid as to > what is wrong with them). There is no process issue with normatively referring to WHATWG specs. Even if there was, see above for an easier solution to the problem than independently writing a parallel spec. You can go *even simpler* if you'd like, because the URL standard is freely licensed; just save a copy of the spec and send it to www-archive, or some other storage with a reasonably stable url, and refer to that instead. It would be silly and quickly outdated, but if that's what you're asking for, the option exists. If there are *actual problems* with the URL standard that you're trying to fix with your spec, I support the effort, though I believe it would be more fruitful to work with Anne on the existing URL spec. If, as your email suggests, you're trying to write this document solely because of perceived W3C Process issues, that's silly and I will oppose the publication of this spec, as it has far too much potential for accidental badness over the other, simpler options. ~TJ
Received on Sunday, 19 May 2013 23:46:46 UTC