W3C home > Mailing lists > Public > www-tag@w3.org > May 2012

Re: Media typing of fragments

From: Robin Berjon <robin@berjon.com>
Date: Mon, 7 May 2012 22:06:03 +0200
Cc: "www-tag@w3.org" <www-tag@w3.org>
Message-Id: <9E89F98C-677F-460C-9AB8-D5C682EB1194@berjon.com>
To: Noah Mendelsohn <nrm@arcanedomain.com>
On May 4, 2012, at 15:50 , Noah Mendelsohn wrote:
> On 5/4/2012 5:42 AM, Robin Berjon wrote:
>> I don't think so. They clearly state that this is "a further requirement" that they are putting on URI fragments. In other words, they're defining the way in which URI fragments are processed within the confines of their specification. I see nothing wrong with the restriction they make as it applies to the specific fragment processing that they have devised.
> That reading is not at all clear to me. The text in question follows a paragraph that explains the difference between query (?) and fragment (#) syntax. In context, the quote is:
> "The main difference between a URI query and a URI fragment is that a URI query produces a new resource, while a URI fragment provides a secondary resource that has a relationship to the primary resource. URI fragments are resolved from the primary resource without another retrieval action. This means that a user agent should be capable to resolve a URI fragment on a resource it has already received without having to fetch more data from the server.
> 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. "
> Certainly that first paragraph is paraphrasing RFC 3986, not providing a narrowed view relating to media fragments. So, if what's intended is the narrower reading you suggest, I think it needs to be worded much more clearly. In context, it appears to be a tutorial on Web architecture, as the first paragraph seems to be in any case.

I don't think that it is intended as a tutorial on Web architecture (which would be a strange thing to include there), rather I think that they are explaining how one chooses between the two large options they standardise to access media fragments. It is built on existing architecture but does not (re)define it.

I see how you could come to the conclusion you reach though. Given that this is explanatory text on a specification that is already well implemented[0] and a Proposed Recommendation the review period for which has been closed for ten days apparently with overwhelming support[1] (i.e. barring Team-only blocking comments, publication as Rec ought to be imminent), I suggest that rather than trying to get formal endorsement from the TAG you request an editorial improvement to the MFWG to clarify that they mean to define the usage of fragments inside the scope of their specification and not for the whole Web.

[0] http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-impl/
[1] https://www.w3.org/2002/09/wbs/33280/medfragpr/results (member-only)

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 7 May 2012 20:06:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:44 UTC