Re: [web-annotation] Is fixing the list of fragment identifiers a good idea?

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?


>
> I think this is a very bad idea. Fragment identifiers are defined all
> the time; by restricting the list to the fragment identifiers we know
> about at the time of publishing the specification we will incur the
> danger of being out of date very quickly and that would require
> updates of the Recommendation. At this moment we are already missing
> some on the list, like:
>
> * fragment identifiers for CSV files, defined by rfc7111 (this is the
> open #26 issue on our issue list)
> * fragment identifiers for EPUB files, called
> [CFI](http://www.idpf.org/epub/linking/cfi/epub-cfi.html)
> * fragment identifiers for PDF, defined in the [PDF mime type
> registration](https://tools.ietf.org/html/rfc3778#section-3)
>
> And these are only a few examples. Within W3C, actually, there is work
>  on, eg., [Web packaging](http://www.w3.org/TR/web-packaging/) that
> may lead to new [fragment
> identifiers](http://www.w3.org/TR/web-packaging/#fragment-identifiers)
>  defined for web packaging formats (and the publishing community *may*
>  come up with alternative for this), and we ourselves may define
> separate fragment identifiers for the RangeFinder API (as a
> serialization thereof). On long term we will loose.
>
> I believe it would be a much better approach to leave this open ended.
>  We should accept fragment identifiers that are officially defined
> either directly as part of a media type specification (as the one for
> PDF above) or as separate RFC-s (like rfc7111). I am sure there is a
> list somewhere maintained by IETF to refer to.
>
> See https://github.com/w3c/web-annotation/issues/40
>
>