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

Hi Julian,

On Jun 29, 2008, at 12:37 PM, Julian Reschke wrote:

>
> Robert J Burns wrote:
>> I still haven't seen a use case or problem statement for why HTML5  
>> cannot use the existing URL/URI/IRI specifications. It would be a  
>> poor  design decision to diverge from the existing specification  
>> son that without a clear problem statement as to why we need to do  
>> so. Specifying document conformance criteria for URLs, URIs, and  
>> IRIs along with HTML5 UA conformance for handling and error  
>> recovery do not constitute a change in the existing definitions. If  
>> we require such a divergence from existing definitions, what  
>> problem are we trying to address? What use cases cannot be met by  
>> the existing specifications? So it seems very premature to be  
>> searching for a new term or word for a definition that we have not  
>> yet developed the need for.
>> ...
>
> Robert,
>
> IRI does not allow spaces. Pages use them. Does that answer your  
> question?
>

No, that doesn't at all address the question. The fact that pages use  
literal spaces (and not percent encoded spaces) in their IRIs does not  
constitute a valid use case or problem statement that would justify  
HTML5 using a different definition of IRI than the RFC definition.  
Instead it is justification for including explicit error recovery for  
IRIs that use spaces.

Keep in mind that I'm responding to the idea expressed in the latest  
draft in the green note:

> Note: The term "URL" in this specification is used in a manner  
> distinct from the precise technical meaning it is given in RFC 3986.  
> Readers familiar with that RFC will find it easier to read this  
> specification if they pretend the term "URL" as used herein is  
> really called something else altogether.

Instead of reinventing the wheel, HTML5 should simply be accepting RFC  
3986 as is and defining document conformance for authoing IRIs and  
URLs UA error recovery for errant IRIs or URLs. If instead HTML5 is  
going to diverge from that approach, I think we should be very clear  
about what use cases or problem statement we're trying to address.

Instead, the WG is engaging in an exercise to try to come up with a  
new name for a concept we haven't even demonstrated we need.

Take care,
Rob

Received on Sunday, 29 June 2008 11:51:13 UTC