- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Sat, 05 May 2012 21:45:10 +0200
- To: Thomas Roessler <tlr@w3.org>
- Cc: "www-tag@w3.org List" <www-tag@w3.org>
* Thomas Roessler wrote: >To put this snippet (and the discussion at the Web conference) in >context, I recommend a look at the charter of the media fragments WG: > >> The mission of the Media Fragments Working Group, part of the Video in >> the Web Activity, is to address temporal and spatial media fragments in >> the Web using Uniform Resource Identifiers (URI) > > -- http://www.w3.org/2008/01/media-fragments-wg.html > >In the conversation at WWW 2012, I took Larry's critique of media >fragments to be against a W3C working group defining semantics for >fragment identifiers. I pointed out that that was the very purpose of >this working group, and said that if people thought this basic approach >was a mistake, then that would have been a point to discuss at >chartering time, not at PR time. The word "fragments" in the quote above refers to "media fragments" like a region of an image; it does not refer to URI fragment identifiers. The Working Group was to investigate URI fragment identifiers as option, it "will investigate the several possibilities in the URI syntax, such as URI fragment identifier or query parameters" per the charter, but that's it. Anyone saying during chartering time using URI fragment identifiers is the wrong idea would likely have been told that the group will inves- tigate and ascertain that if so, so that would not have been the time. I don't know anyone is actually arguing that using URI fragment identi- fiers is wrong for this, but in any case, the fundamental problem with that is that the interpretation of URI fragment identifiers depends on the media type of the resource. So without updating media type specifi- cations, the Media Fragments specification cannot actually define seman- tics for URI fragment identifiers. And it doesn't, it just offers people who define media types to reference the Media Fragments specification for their fragment identifier syntax. >There's a separate question what the exact coordination needs are at >this point, how they are best dealt with, and what communication needs >to go back to the IETF. As W3C liaison to the IETF, I re-iterate my >request that TAG members put coordination issues on the agenda of >W3C/IETF liaison meetings, where these belong. Interfering in the work >of the liaisons is not helpful. Well, very early on the Working Group had an issue "Does our MF URI syntax imply that we need to update MIME Type registrations?" That one got resolved by a new issue "Write a IETF draft for proposing how to register the fragment scheme for all media types" which a year later was merged into the issue "Create a IETF draft at CR stage explaining what the media fragment semantics will be for video/*, image/*, audio/*", see the "IETF and TAG updates" section in the minutes here, http://www.w3.org/2010/11/02-mediafrag-minutes.html#item03 I note that this issue isn't new to W3C's IETF liaisons, see e.g. the thread at <http://www.w3.org/mid/1271782569.4466.7439.camel@pav.lan>. Then, after the document got approved for publication as Candidate Recommendation, the Working Group decided they would rather not write such a document during the Candidate Recommendation phase after all, and specifically asked W3C's IETF liaison how to handle the matter, http://www.w3.org/mid/C784B1A6-63BB-4445-B9EF-3603E30FE56B@ugent.be I am not aware of any response or reaction. Dan Connolly had this to say, "It doesn't seem responsible for W3C to Recommend the media fragments spec without some plan in place to get the IETF/IANA registrations updated." and "It's not polite for W3C to unilaterally encourage implementations to deploy certain designs that will constrain updates to IETF RFCs." That's what the W3C is doing. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Saturday, 5 May 2012 19:45:38 UTC