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

On Thu, 13 Mar 2008, Brian Smith wrote:
> 
> Section 1.4 says "For readability, the term URI is used to refer to both 
> ASCII URIs and Unicode IRIs, as those terms are defined by RFC 3986 and 
> RFC 3987 respectively. On the rare occasions where IRIs are not allowed 
> but ASCII URIs are, this is called out explicitly."
> 
> First, this policy isn't followed in the document; there are many places 
> in the document where the phrase "URI (or IRI)" is used. Secondly, this 
> is backwards and confusing, because every URI is an IRI, but not every 
> IRI is a URI.

This has now been fixed.


> Instead, the term "IRI" should be used throughout, except where only 
> URIs are allowed. In addition, whenever non-URI IRIs are forbidden, 
> there should be an explanation of why they are forbidden.

Since the way that these values are treated doesn't actually follow IRI 
rules, I've used the term "URL" instead.


> The DOM "interfaces for URI [sic] manipulation" in section 4.13 should 
> be amended to provide a mechanism for converting between IRIs and URIs. 

What's the use case for this?


> Also, some description of how the DOM interfaces deal with IRIs is 
> needed. In particular, can I pass an IRI directly to 
> XMLHTTPRequest.open(), or do I need to convert it to a URI (URL) first?

That's an issue for the XHR spec. For other APIs, I've defined it in HTML5 
now.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 27 June 2008 23:38:00 UTC