Re: All you need is URL

Hi all,

Many W3C working groups have wrestled with this problem for many years. The
RDF Working Group migrated their specs to use IRIs just a few months before
the IRI group gave up :(

The obvious problem is that many use cases do require a differentiation
between online-accessible and offline-only content. Does that sound useful
or familiar for the Publishing WG?

Regards,
Dave

On 16 August 2017 at 02:26, Cole, Timothy W <t-cole3@illinois.edu> wrote:

> 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> 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>
> *Date: *Tuesday, August 15, 2017 at 3:25 AM
> *To: *Leonard Rosenthol <lrosenth@adobe.com>
> *Cc: *W3C Publishing Working Group <public-publ-wg@w3.org>
> *Subject: *Re: All you need is URL
>
>
>
> On 15 Aug 2017, at 02:20, Leonard Rosenthol <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 <+31%206%2041044153>
> 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=>
>
>