W3C home > Mailing lists > Public > public-publ-wg@w3.org > August 2017

RE: All you need is URL

From: Cole, Timothy W <t-cole3@illinois.edu>
Date: Tue, 15 Aug 2017 16:26:43 +0000
To: Ivan Herman <ivan@w3.org>, Leonard Rosenthol <lrosenth@adobe.com>
CC: Romain <rdeltour@gmail.com>, W3C Publishing Working Group <public-publ-wg@w3.org>
Message-ID: <EECC28A63F2ED74B8420079BBE599453617F5D56@CITESMBX6.ad.uillinois.edu>
The corollary to conflating URL and URI (and then dropping any use of URI in our docs), is that URLs must be understood to be more than dereferenceable network addresses via which information can be accessed and retrieved; they can also serve simply as opaque identifiers. As expressed in the current version of the whatwg definition: "Typically a host [subcomponent of URL] serves as a network address, but it is sometimes used as opaque identifier in URLs where a network address is not necessary." (https://url.spec.whatwg.org/#host-representation).

This is certainly a reasonable position for us to assume, and is consistent with emerging community consensus and standards, I think, but it is not an understanding that is yet universal - many folks I work with in my community assume (incorrectly according to today's standards) that a URL is ALWAYS a network address. Though it is stated (e.g., see above) that this is not the case in the definitions of URL we are referencing, given the long history for many of us of distinguishing between URI and URL and for the benefit of our audience, I suggest we will want to highlight that URLs are not always network addresses and that it is okay to use a URL not only as a locator or address via which content is accessed or retrieved, but also as a means to simply identify content or a concept that may or may not be retrievable (e.g., Leonard's namespace example earlier in this thread).

So even as we drop URI and IRI, we will still need (as was the consensus yesterday, I think) to retain definitions of Web Publication identifier and Web Publication address and to use the terms identifier and address appropriately in our document. In our context there is a meaningful distinction between identifier and address even when the same syntax is used to express both, and if we define persistence as a feature of identifier but not address, then neither is a subset of the other.

Not being an expert in internationalization, I have no opinion about whether IRI as distinct from URL remains useful.

-Tim Cole

________________________________
From: Ivan Herman [ivan@w3.org]
Sent: Tuesday, August 15, 2017 06:56
To: Leonard Rosenthol
Cc: Romain; W3C Publishing Working Group
Subject: Re: All you need is URL


On 15 Aug 2017, at 13:49, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:

The problem with using the WhatWG spec is in its definition - “a continually updated specification” (and therefore *not* a standard!).  This is going to be especially true as we consider our archival requirements and the need to have a standard that can be referenced “in perpetuity”.

This is a problematic issue indeed, but I would propose to leave this to those who make these decisions. If the HTML spec can have a reference to this document (based on all kinds of special discussion on the matter) then we can certainly follow suit. (We can have that issue discussed with the Director later.)

Ivan



Leonard

From: Romain <rdeltour@gmail.com<mailto:rdeltour@gmail.com>>
Date: Tuesday, August 15, 2017 at 3:25 AM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Cc: W3C Publishing Working Group <public-publ-wg@w3.org<mailto:public-publ-wg@w3.org>>
Subject: Re: All you need is URL


On 15 Aug 2017, at 02:20, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:

We agreed to use the definition in the HTML 5 spec, which is an acceptable normative reference for URL.

Correct, and the only normative reference in W3C's HTML is the URL Standard by WhatWG:
  https://www.w3.org/TR/html/references.html#biblio-url<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.w3.org-252FTR-252Fhtml-252Freferences.html-2523biblio-2Durl-26data-3D02-257C01-257C-257Cc406e51eb66a438a331a08d4e3aec7d7-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636383787205622453-26sdata-3D7kLP9XAC6Cs8EpJrzl9tsFrWG8JzgR8qs15KXN-252FbcP0-253D-26reserved-3D0&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=0-XBkiC5GoLon2dw9f0jbVbUnc-JAlNvQ9rzp8HAUtw&s=ONdTCHbvyWb_Jxi1pRVK3L0DIN9cdnTtvZS-uqG73kM&e=>


However, there are times where we may want/need a URI or IRI, such as when we need something that isn’t actually a “link” on the web (eg. a namespace).

That's where I disagree: the URL reference we agreed upon does obsolete URI or IRI, and it isn't just about "link" on the web.
So when, exactly, would we need to use "URI" or "IRI", except perhaps in an explanatory note alongside the [URL] reference?

I don’t recall anyone suggesting a specific use case for URN.

URNs were mentioned several times in call discussions on IRC.

My email was to debunk stuff like "URI = URN + URL", or "URN is not a URL", or "URL is only for a “link” on the web", which is untrue with the normative reference we agreed to use.

Romain.






----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_People_Ivan_&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=0-XBkiC5GoLon2dw9f0jbVbUnc-JAlNvQ9rzp8HAUtw&s=Foe1SbLsgR0eBipqXwkze1DlwQZNOp-7EJ_UmdPAbO4&e=>
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704<https://urldefense.proofpoint.com/v2/url?u=http-3A__orcid.org_0000-2D0003-2D0782-2D2704&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=0-XBkiC5GoLon2dw9f0jbVbUnc-JAlNvQ9rzp8HAUtw&s=RT1YtSF3COpyfLukj9ZDn9Mlshb6a9wNO68vXzzPIho&e=>
Received on Tuesday, 15 August 2017 16:27:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:49:06 UTC