Re: ISSUE-56: urls-webarch - suggest closing on 2009-09-03

Hi Dan,

On Aug 24, 2009, at 6:41 AM, Dan Connolly wrote:

> A comment with the WONTFIX includes:
>
> | The real solution is for the URI and IRI specs to be merged, for the
> URI spec
> | to change its definitions to match what "URL" is defined as in  
> HTML5 (e.g.
> | finally defining error handling as part of the core spec), and for  
> everyone to
> | stop using terms other than "URL".
>
> I think that's an interesting idea, if anybody is serious about
> taking it up. I don't know how long it would take... I can't imagine
> it happening in time for last call.
>
> Without an actual plan to take on that work, marking 7392 as WONTFIX
> seems to leave the job half done.

Here's my take on this issue. I think two things need to happen:

1) We need to get the references in order first, because whether HTML5  
references Web Address, or IRIbis, or something else, makes a  
difference to what we'll think about the naming issue. Larry has taken  
an action due at the end of September to update IRIbis based on  
feedback.

2) We need to decide as a Working Group if it's acceptable to use the  
term URL in a different way than RFC3986 (while making the difference  
clear). If it's unacceptable, then we need to propose an alternate  
term. I think the editor is not inclined to change the terminology of  
his own accord (I asked both about replacements like "Web address" or  
"HREF"; and decorations like "HTML URL", "Web URL" or "URL  
reference"). He expressed to me the opinion that using a completely  
new term would disagree with the colloquial understanding of authors  
and implementors, and that a decorated term with "URL" in it somewhere  
would be ugly.

On point (2), I am personally indifferent. It's my experience that  
when Web developers or UA implementors say "URL", they typically mean  
it in the extended sense that matches the behavior of URL-valued  
attributes in HTML. On the other hand, I can see the argument that  
using the exact term "URL" in a way that conflicts with the  
controlling RFC could produce confusion. I don't really have an  
aesthetic concern with any of the kinds of terms suggested, and I also  
don't see "URL" itself as a hard spec conflict.

All that being said, I suggest we table (2) until (1) is resolved, and  
leave the issue open in the meantime.

Regards,
Maciej

Received on Tuesday, 25 August 2009 00:47:49 UTC