Comment on Media Fragments URI 1.0 (basic) Proposed Recommendation 15 March 2012

During the course of some TAG discussion of the Media Fragments URI 1.0 
(basic) Proposed Recommendation [1], I was confused and concerned by some 
of the text in section 3.1. Quoting the text in question:

==================
A further requirement put on a URI fragment is that the media type of the 
retrieved fragment should be the same as the media type of the primary 
resource.
==================

I read this as attempting to restate a constraint from RFC 3986 on the 
resolution of fragment identifiers, and there is of course no such constraint.

During informal discussions with some TAG members who have followed your 
work more closely than I have, it was suggested that your intention was 
only to introduce a constraint that you choose to impose for your 
particular purposes. If so, I suggest an editorial clarification, perhaps 
along the lines of:

==================
This specification imposes a further constraint, which is that the media 
type of the retrieved fragment should be the same as the media type of the 
primary resource.
==================

(I might also quibble with the use of the word "retrieved" in this context; 
I presume that a given fragment identifies, e.g., a given frame in a video 
regardless of whether a retrieval has been done. This is important for uses 
like RDF, in which we might want to make a statement about a video frame 
which has not necessarily ever been retrieved by anyone.)

Anyway, I think that the corrections I'm suggesting are editorial in 
nature, and I hope you will consider making them before going to 
Recommendation. Please note that, although TAG members were helpful to me 
in understanding the issues here, this is a personal comment, and it is not 
offered on behalf of the TAG, or in my role as TAG chair. Thank you very much.

Noah

[1] http://www.w3.org/TR/2012/PR-media-frags-20120315/
[2] http://www.w3.org/TR/2012/PR-media-frags-20120315/#URIquery-vs-fragments

Received on Monday, 14 May 2012 20:59:18 UTC