Do we need fragment ids?

[iherman]

The document consists of two parts: a description of, essentially, the Selector Model as defined by the Web Annotation Data Model, and a reformulation of that data model in the form of Fragment ID-s. It is not clear, at this moment, whether the standardization of fragment identifiers is necessary, or whether the JSON based structure fulfills the needs of the requirements. If the latter, we can remove the relevant section, and the only possible normative extension in the document is described in issue #4.

[iherman]

The latest PR (#8) has examples for Fragment ID-s for more complex selectors; I personally believe that this is at the very limit of usability in terms of URL-s. If the use cases can be handled using JSON structures (I see mainly bookmarking and annotations as use cases for this features, much like these were the only use cases EPUBCFI was really used for) then my current feeling is that we should not introduce fragment id-s...

[TzviyaSiegman]

Aside from the obvious difficulties of creating a fragment identifier when there is (probably) not a media type, it seems to me unlikely that the fragment identifier would be more useful than EPUBCFI. EPUBCFI has been useful to UAs, and I think we need to hear from the UA developers to understand if this proposal works. cc @GarthConboy @rickj @rkwright

[tcole3]

From the 2017 TPAC f2f, the preliminary consensus answer to this issue question is NO (we should not include a section in the Web Pub Locator spec for translating locators to fragment ids), for the reasons listed below. A PR to remove fragment ids from the Locator draft will be generated for review by the WG at an upcoming call. If PR accepted, this issue will be closed.

Pro mentioned during f2f:

• EPub 3.1 uses Fragment Ids

Cons mentioned during f2f (incomplete list):

• No compelling use case, even from those using EPUB 3.1 CFIs;
• Browsers and other generic implementations of the Web Platform currently have no idea how to handle Web Pub Locators as fragment ids;
• A fragment id scheme meant to be applied to a range of media types, must be registered (accepted) for each media type - this is unlikely;
• A locator fragment id cannot be added to a resource that itself is identified by a URL that includes a fragment id (limiting the applicability and usefulness of locators as fragment ids);
• Locators can get complex (and therefore lengthy) and fragment ids have practical length limits (again, limiting the applicability and usefulness of locators as fragment ids).

[BigBlueHat]

+1 We all seemed to agree that defining a cross-mediatype selector system was too far a reach (and likely a fool's errand even if we tried).

I think there's still high likelihood we will need a fragment identifier scheme for PWP, however, but I think that one would be more about referencing the resources within the package--rather than selections within those resources.

[lrosenthol]

I disagree on this one. I think that fragment IDs for WP and PWP is extremely important for being able to have a link from one publication to another, when you don't have the ability to edit the destination. As pointed out in the meeting (by @BigBlueHat, I believe) it is all the same use cases we had for XPointers.

That said - I do not believe we have to translate all selectors to fragments! I think we can look at each of them and the use case(s) and limit the set. (offhand, I think CSS and path selectors would suffice)

[iherman]

@lrosenthol,

I think that fragment IDs for WP and PWP is extremely important for being able to have a link from one publication to another, when you don't have the ability to edit the destination.

I do understand that, but, if we go down that line, then we have to answer the issue of fragment ID registration. Which mime type(s) would that fragment ID defined for? I would guess text/html and image/svg+xml at the minimum. (Maybe MathML, too, but that may be a stretch.) Those mime types are "owned" by the Web Platform WG and the SVG WG, respectively, ie, they have to accept to register the Fragment ID. I foresee major difficulties in doing so. (Let alone the stupid admin problem that I am not sure there is a registration mechanism at IANA for an additional fragment ID for a mime type that has already been registered.)

Somebody mentioned during the discussion (I do not remember who that was) that we could consider registering the fragment ID with a mime type for WP (provided we defined one). But I do not think that would work either: what we can register easily is a media type for the publication manifest, ahem, waybill, because that is definitely a specific resource that may have a URI. I am not sure that, for IANA, registering a mime type which represents more than one resources would be acceptable. On the other hand those fragment ID-s are used for specific resources, that have their own mime type (those mime types also appear in the Web Packaging approach); per Web architecture, that resource is served as, say, text/html, in which case a fragment ID registered for the WP mime type would be irrelevant.

(We could register the fragment ID for a PWP, as opposed to WP, much like EPUBCFI is assigned to the EPUB Mime type. But that would not be really acceptable if one uses the WP.)

My conclusion at this point is that, although I do understand the reasons of having them, a proper registration, ie, a proper specification of these fragment ID-s would have to overcome major hurdles, if at all it is possible. I am not convinced it is worth it.

That said - I do not believe we have to translate all selectors to fragments! I think we can look at each of them and the use case(s) and limit the set. (offhand, I think CSS and path selectors would suffice)

I am not sure how we would define which subset should be defined and which would not. What about the "compound" ones, ie, refinement, range, multi resource? I would think those are clearly important, too. In other words, we may leave out one or two, but that would not simplify things too much, let alone the fact that the complication surrounding the registration would remain no matter what...

[tcole3]

As noted elsewhere, Section 6.5.1 of WPub current draft, existing frag id schemes can of course be used. So existing fragment identifier schemes for HTML, XML, PDF, other relevant text formats, media fragments are all available as way to directly link into a chapter, embedded image, article or whatever. They do so, however, without reference to the parent Web Publication.

The current draft of /w3c/publ-loc introduces the idea of an additional frag id scheme that would additionally support Text Quote Selectors, Text Position Selectors, etc. on multiple media types. I agree @iherman and @BigBlueHat that this approach is probably not viable as a new fragment id scheme for HTML, XML, PDF, other relevant formats in the near term for the reasons they've enumerated. So for FPWD of Locators I'd rather rather remove this approach for now. Can always add back in if we have compelling enough use cases and if assessment of viability changes.

But what might be more feasible instead (though not for FPWD) and more like what EPub CFI allows would be a new fragment id scheme for the WayBill (manifest) of a WP and/or for PWPs. This is where I would disagree somewhat with @iherman. I think having a PWP or WP specific fragment id scheme could be worthwhile, and I would contend that it would naturally be limited to the Embedded Resource Selector, because this is the only Selector that is designed to be appended to a WP or PWP URL. But all the other Selectors then become available as refinements of the ERS. And in this scenario, the parent WP or PWP is referenced.

I think this is part of what @BigBlueHat was getting at. Fragment identifiers for PWP also could help us address the concern that PWPs might package resources that don't have their own URLs - i.e., you could refer to them via a fragment id scheme that relies on relative addressing.

So my proposal is to take out of current Locator draft the Selector to Fragment id mapping section for now, wait and see whether we decide to define media type for WP WayBill (possibly) or PWP (likely?) and then if so, consider bringing Selector-to-Frag Id mapping back specifically for Embedded Resource Selectors, with refinement.

[iherman]

I agree, @tcole3. I see where you are going with the possible (P)WP specific fragment ID; if it is restricted to, essentially, selecting a resources within (P)WP, it may indeed be useful in simplifying some of the selector schemes (although I am not sure it would make the ERS unnecessary).

My proposal would be, from an administrative point of view to

1. Remove the current fragid section from the document
2. Open a new issue on that possible fragment ID (and add a reference to that issue from the draft)

[lrosenthol]

@iherman and @tcole3 - I am OK with the two suggestions above, but I would add a third, which is to open an issue with the WebPlatform WG (or whatever it is these days) about fragments to non-editable content.

[tcole3]

Okay, I will do steps 1 and 2 and add issue and create PR (but probably not until Monday).

Need to think further about @lrosenthol 's step three and understand best way to pursue.

[tcole3]

Thoughts carried over from the discussion of now closed PR #35:

Given that we are not in a position to specify a new kind of fragment identifier for existing media-types, e.g., UAs already have a model for parsing fragment ids appended to URLs that resolve to HTML media type resources and are unlikely to accommodate substantial changes to this model for our use case, we need to rewrite or remove the section of our current draft entitled, Selectors, Positions, and States as Fragment Identifiers. There are 4 ways we could go - as of 27 Nov WG call the consensus is for 1:

0. We could remove any definition of ways to serialize locators as fragment identifiers (which we likely will do if no new media type is proposed for at least one of WPub or PWPub).

1. We could define a fragment identifier scheme for expressing (mostly) unrefined Embedded Resource Selectors only (which would simplify greatly, a PR will be created to do this).

2. We could define a fragment identifier scheme for expressing both refined & unrefined Embedded Resource Selectors (much less simplification)

3. We could define a fragment identifier scheme for expressing any of the 3 new Selectors which are meant to work with collective resources like WPubs and PWPubs (even less simplification and what was proposed in PR Narrow Scope of Fragment Ids #35 ).