- From: Ted Hardie <ted.ietf@gmail.com>
- Date: Mon, 15 Oct 2012 07:30:26 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Larry Masinter <masinter@adobe.com>, Robin Berjon <robin@w3.org>, "plh@w3.org" <plh@w3.org>, "Peter Saint-Andre (stpeter@stpeter.im)" <stpeter@stpeter.im>, "Pete Resnick (presnick@qualcomm.com)" <presnick@qualcomm.com>, Martin Dürst (duerst@it.aoyama.ac.jp) <duerst@it.aoyama.ac.jp>, "www-archive@w3.org" <www-archive@w3.org>
On Sat, Oct 13, 2012 at 2:15 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > Oh, also, you guys keep mentioning "HTML5". This really is about all > URLs everywhere, XMLHttpRequest, CSS, HTTP Location header, SVG > xlink:href, SVG href, etc. I think this summarizes the primary disconnect: that "all URLs everywhere" is limited to the web. There are flocks of URLs/URIs in use outside the web, and there needs to be a very basic agreement of whether the development of common methods for parsing and other handling *across the web and non-web use cases* is a goal or a non-goal. My personal opinion is that it should be a goal, but the primary need at this point it is to get that issue cleared up. If we are going to end up seeing a fork of web-related identifiers from the rest of URIs, we will need a method for distinguishing the two paths from the fork. One of worst results of this would be re-using the same terms for non-interoperable systems. Bits of spec lose framing context very easily, and if a phrase like "This slot holds a URI" can't be an interpreted without working out which meaning of URI is at issue, the result will be, to quote Sir Topham Hatt, "confusion and delay". My two cents, without any hats on, Ted Hardie
Received on Monday, 15 October 2012 14:30:54 UTC