- From: Raphaël Troncy <raphael.troncy@eurecom.fr>
- Date: Sun, 19 Apr 2015 16:01:46 +0200
- To: Robert Sanderson <azaroth42@gmail.com>, Ivan Herman <ivan@w3.org>
- CC: Paolo Ciccarese <paolo.ciccarese@gmail.com>, W3C Public Annotation List <public-annotation@w3.org>, Bill Kasdorf <bkasdorf@apexcovantage.com>, Tzviya Siegman <tsiegman@wiley.com>, Markus Gylling <markus.gylling@gmail.com>
Dear Rob, > The concerns about the approach are documented here: > http://www.w3.org/TR/annotation-model/#fragment-uris I wanted, some time ago, to suggest a change in the example used in this section, so that a temporal media fragment URI is used in the example instead of a spatial media fragment. The reason is simply that http://example.org/image.jpg#xywh=100,100,300,300 links are much less used than http://example.org/video#t=10,40 ones which are now very popular. > My personal position is that selectors should not be turned into > fragments, because (especially) that would break the rules of fragment > identifiers as laid out in RFC 3986: > > The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. This statement (from RFC 3986) is correct but I disagree with your interpretation. You will not break any rules in the vast majority of cases for the simple reason than most of the media-types do NOT define the semantics of the fragment identifier. Hence, no semantics is defined for audio/*, image/*, video/*. For HTML, XML or SVG, W3C has control for defining the semantics of the fragment identifier. EPUB seems to be willing to get guidance to define this semantics. There is also work on identifiers for CSV. Etc. Best regards. Raphaël -- Raphaël Troncy EURECOM, Campus SophiaTech Multimedia Communications Department 450 route des Chappes, 06410 Biot, France. e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com Tel: +33 (0)4 - 9300 8242 Fax: +33 (0)4 - 9000 8200 Web: http://www.eurecom.fr/~troncy/
Received on Sunday, 19 April 2015 14:02:16 UTC