- From: Justin James <j_james@mindspring.com>
- Date: Sat, 28 Jun 2008 12:16:51 -0400
- To: "'Smylers'" <Smylers@stripey.com>, "'HTML WG'" <public-html@w3.org>
> But most people's concept of precisely what constitutes a URL is pretty > fuzzy. It isn't clear that what they think of on reading "URL" matches > the existing definition but not the HTML 5 one. The nuances between > those definitions probably don't even register with many people, meaning > that the change doesn't affect them: their general idea of what a URL is > matches the HTML 5 definition just as closely as it does the original. I have not seen a *single* person on this list say, "hey, this is an important distinction at a functional level". Every person involved here (Brian Smith, Julian Reschke, Smylers, Mark Baker, Phillip Taylor, myself) all agree that the distinction is meaningless except in one extremely narrow use case: people with an intimate knowledge of the URL/IRI/URI spec(s) who are implementing something in which the distinction is important. I posit that this use case is irrelevantly small; it only seems to apply to people attempting to write applications that implement a particular spec, or maybe people writing an "URIBuilder" type library component or something. To "real world" people, this is Yet Another Spec That Shall Be Ignored. By trying to find some way to have all of these slightly different items play nicely with each other, we're dancing around the elephant in the room (I know, Managerial Speak) which is that there should only be one *RI/L spec. PERIOD. So let's stop this silly dance, get with the *RI/L group, and tell them, "this is broken, please provide us with 1 unified spec that makes sense." But for us to keep trying to Band-Aid the broken *RI/L situation within the HTML spec itself is pretty pointless. *RI/L is meta to HTML, and not within our purview. J.Ja
Received on Saturday, 28 June 2008 16:17:42 UTC