RE: Confusing use of "URI" to refer to IRIs, and IRI handling in the DOM

> 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