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

+1 seems the right thing to do.

On Thu, Jun 25, 2015 at 10:35 AM, Jacob <notifications@github.com> 
wrote:

> +1
>
> On Thu, Jun 25, 2015 at 10:23 AM, BillKasdorf 
<notifications@github.com>
> wrote:
>
> > +1
> >
> > From: Ivan Herman [mailto:notifications@github.com]
> > Sent: Thursday, June 25, 2015 7:02 AM
> > To: w3c/web-annotation
> > Subject: [web-annotation] Is fixing the list of fragment 
identifiers a
> > good idea? (#40)
> >
> >
> > 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.
> >
> > 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<https://github.com/w3c/web-annotation/issues/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.
> >
> > —
> > Reply to this email directly or view it on GitHub<
> > https://github.com/w3c/web-annotation/issues/40>.
> >
> > —
> > Reply to this email directly or view it on GitHub
> > <
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_web-2Dannotation_issues_40-23issuecomment-2D115274690&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=npggDwlZ6PziBzPBZthSo0f8iGOgRMf9ulO6o4WwfiA&m=5iKhJnAEaeL1dVrXZhwfmgnG7bY50SAWkTQe1YdvY48&s=nRk8wE2XKSOl2dUjXrgd6gOxYnYS6wvV3B4hJ8uv2qs&e=
> >
>
> > .
> >
>
> —
> Reply to this email directly or view it on GitHub
> 
<https://github.com/w3c/web-annotation/issues/40#issuecomment-115277804>.
>



-- 
Dr. Paolo Ciccarese
Principal Knowledge and Software Engineer at PerkinElmer Innovation 
Lab
Assistant Professor in Neurology at Harvard Medical School

Assistant in Neuroscience at Mass General Hospital
ORCID: http://orcid.org/0000-0002-5156-2703


-- 
GitHub Notif of comment by paolociccarese
See 
https://github.com/w3c/web-annotation/issues/40#issuecomment-115284651

Received on Thursday, 25 June 2015 14:57:54 UTC