- From: Simone Fonda <fonda@netseven.it>
- Date: Tue, 27 Aug 2013 12:59:26 +0200
- To: Robert Sanderson <azaroth42@gmail.com>
- Cc: Christian Morbidoni <christian.morbidoni@gmail.com>, public-openannotation <public-openannotation@w3.org>
On Sun, Aug 25, 2013 at 7:27 PM, Robert Sanderson <azaroth42@gmail.com> wrote: > Assuming you mean section 2.1.4, it talks about fragments for HTML > rather than xpointers. The reason being, of course, that you can't use > an xpointer as a fragment for HTML. If we do say somewhere that > xpointers can't do that, we should change it :) You're absolutely right, the spec talks about HTML fragments, which, following the specs, are not xpointers. My bad! >> The discussion evolved to "how can we use xpointers and be >> spec-compliant", and on this topic i have another question: can't we >> use the xpointer spec for the fragment part and specify an explicit >> dcterms:conformsTo? Isnt this mechanism supposed to fill exactly this >> use case (read: tell the consumer how to interpret the fragment >> semantic)? > > No, because FragmentSelector says that you can join the hasSource and > the selector's rdf:value to form a valid fragment URI, and you can't > do that with an xpointer. Mh, Ok. It must be valid for the exact media type of the source. It's clear now. Though, still believe that it would have been fun (and maybe useful) allowing funky fragmentSelectors like an #xywh=* of an HTML page, or #char-* of content coming from a PDF, or any other combination. But since this can be done simply by defining a new selector, we will just follow that road when needed. Thanks again for the clarifications! :) Simone
Received on Tuesday, 27 August 2013 11:00:24 UTC