W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > August 2019

Re: [dxwg] Clarify need for unambiguous profile URIs when compound specifications referenced. (#1017)

From: Nicholas Car via GitHub <sysbot+gh@w3.org>
Date: Thu, 08 Aug 2019 13:41:33 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-519523034-1565271692-sysbot+gh@w3.org>
Regarding the 'hook' statement:

The specification, in the Abstract Model's [6.2 Profile Identification](https://raw.githack.com/w3c/dxwg/conneg-ACTION-356/conneg-by-ap/index.html#profileid) states:

> A client requesting the representation of a resource conforming to a profile MUST identify the resource by a Uniform Resource Identifier (URI) [RFC3986] and MUST identify a profile either by a URI or a token that unambiguously identifies the profile for the server within that request/response session. 

So, from this document's point of view identification by URI is mandated.

Regarding the "separate URI and not a URI with document fragment": 

The specification never mentions fragment URIs, only URIs, and, for profile identification, also tokens that map to URIs. While servers strip off URI fragments when resolving them and leave clients (web browsers) to navigate (scroll) to the fragment-identified part in a served resource, the identification role of a URI including a fragment uses the whole URI. so yes, URIs + fragments can be used to identify profiles and this is normal URI use.

It would be a matter for perhaps Guidance to flesh out how/why people could/should allocate URIs, with or without fragments, to document/specification portions.

So since I don't think any change is needed to the conneg doc here, I'm marking this 'due for closing' and will close in a week unless there is any thing else raised here.

GitHub Notification of comment by nicholascar
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1017#issuecomment-519523034 using your GitHub account
Received on Thursday, 8 August 2019 13:41:35 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:28:31 UTC