- From: Ivan Herman via GitHub <sysbot+gh@w3.org>
- Date: Tue, 30 Jun 2015 15:36:42 +0000
- To: public-annotation@w3.org
(There is a certain mess on where to have the discussion, github or mailing list. For the good order I copy Benjamin's comment here, originally [sent to the mailing list](http://www.w3.org/mid/CAE3H5FKtmz-dvuSOWrxztmFqWxKRs=eLOLR4w2B-gj5hr2P24Q@mail.gmail.com)) From: Benjamin Young Sorry to weigh in late on this...was out last week. On Thu, Jun 25, 2015 at 7:02 AM, Ivan Herman via GitHub <sysbot+gh@w3.org> wrote: > iherman has just created a new issue for > https://github.com/w3c/web-annotation: > == Is fixing the list of fragment identifiers a good idea? == I was re-reading the [fragment selector](http://www.w3.org/TR/annotation-model/#h4_fragment-selector) section in the model document; my reading is that the Recommendation would fix the fragment selectors that a conforming implementation can use. In what way does the spec limit the fragment selectors available? To me the prose reads pretty open handedly, but the list following doesn't state that it's non-normative or just there for examples. For instance: "The Web Annotation model defines a fragment-based Selector (oa:FragmentSelector) which allows both existing and future fragment specifications to be used to describe the segment of interest." It seems that `dcterms:conformsTo` is included precisely to allow future fragment identifiers to be used as values of `oa:FragmentSelector`. It's even OK (though not recommended) for the URL stored as the target to include the fragement--in which case it would fall back to the URI spec, which in turn states that media type registrations (done at IANA) are the source of the meaning of fragments. Perhaps the main action is to fix the text above the list, so it's clearly non-normative or just by way of example? The prose doesn't seem to trip up my using RFC350349234 and it's new brain region fragment identifier. ;) Thoughts? -- GitHub Notif of comment by iherman See https://github.com/w3c/web-annotation/issues/40#issuecomment-117231361
Received on Tuesday, 30 June 2015 15:36:43 UTC