This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section: http://www.whatwg.org/specs/web-apps/current-work/#global-identifiers-for-items Comment: URNs are URIs but not URLs Posted from: 91.61.41.178
Depends on whether you read "URL" as "URL as defined by RFC3986", or as "URL as defined by HTML5". (should we count the confused readers?)
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The term "URL" is hyperlinked to a definition that includes urn: URLs. Anyway, some people are suggesting that urn: can be used for resources that can be located (e.g. in the File API), so it's clear that that scheme _can_ be locatable. So I don't think it's even wrong per the latest changes to the meaning of URI/URN/IRI. We (the standards community) really need to give up on this naming nonsense and just go back to URL, which is what everyone else calls them.
Note that change proposal http://lists.w3.org/Archives/Public/public-html/2010Feb/0882.html for ISSUE-56 (http://www.w3.org/html/wg/tracker/issues/56) at least explains that this specification uses "URL" in ways different than the rest of the web community (and also, by using URL for relative forms) in ways that are not even common in the public literature. Note also that the IETF document draft-ietf-iri-3987bis (http://tools.ietf.org/wg/iri/draft-ietf-iri-3987bis/) contains advice about using "URL" in formal documents, and there is a bug report http://trac.tools.ietf.org/wg/iri/trac/ticket/9 which discusses that issue. Since the response to this bug was "We (the standards community) really need to give up on this naming nonsense and just go back to URL, which is what everyone else calls them.", it would seem appropriate get the standards community to follow that advice. See also http://masinter.blogspot.com/2010/03/resources-are-angels-urls-are-pins.html for some history.
Returning to WONTFIX since no new information has been added since comment 2.
Comment #4, which says that comment #3 contains "no new information", is specious. This is an editorial bug, not a specification bug, and comment #3 contains new information not present before about the editorial status. This bug could be linked to ISSUE-56, but it is actually a separate issue, the use of the term "URL" in the HTML specification, vs ISSUE-56 which covers the relationship between the HTML specification and the IRI specification The first change proposal for ISSUE-56, http://lists.w3.org/Archives/Public/public-html/2010Feb/0882.html also addresses this bug. The second change proposal: http://lists.w3.org/Archives/Public/public-html/2010Apr/0147.html does not. So if the second change proposal for ISSUE-56 is accepted, then this (editorial) bug needs to be escalated to another issue.
I believe this is ISSUE-78: http://www.w3.org/html/wg/tracker/issues/78
ISSUE-78 is (was) already marked as CLOSED. (ISSUE-78 did have an offer to write a change proposal, although not on a schedule to the satisfaction of the chairs.) ISSUE-78 is different, in that it explicitly calls for changing URL in the HTML document. The 'bug' here is that even if the terminology isn't changed, the terminology differences should be explained. In any case, TrackerRequest was not added according to the decision policy because: (a) I do have access to the tracker, and *could* open my own issue (b) TrackerRequest bugs should suggest a title. I'm not going to open an issue at this point, but wanted to note the anomaly that something could transition from TrackerRequest to TrackerIssue without the bug actually being mentioned in the body of the issue, as is required. (Presumably doing so would be 'new information' which would cause the issue to re-open.)