Narrow Scope of Fragment Ids

[tcole3]

Assumes that PWPub resources will have their own media type and that fragment ids will be useful for selecting and locating content in PWPubs. Also made a couple of minor editorial corrections in Appendix A that will need to be addressed if this PR is rejected.

---

Preview | Diff

[tcole3]

As I see it, other Selectors involving multiple resources (currently Span Selectors and Multi Resource Selectors) are dependent on availability of Embedded Resource Selectors, so I would not want to replace the ERS with a fragment id as it would introduce a modeling complexity for those other two selectors and generally splinter the modeling approach overall.

But to your larger point, short of dropping fragment identifiers (Section 7) altogether, the focus of the current fragment identifier section of the spec could still be narrowed to any of:

• unrefined Embedded Resource Selectors (which would simplify greatly)
• refined & unrefined Embedded Resource Selectors (much less simplification)
• any of the 3 new Selectors which are meant to work with collective resources like WPubs and PWPubs (what I do in this PR).

I chose the last since this was the minimum required to avoid the problem of trying to register a new fragment identifier scheme for lots of existing media types. In other words if we want to limit use of selector fragment identifiers to media type(s) that we might introduce as part of PWPub or WPub, then we could consider all 3 of these selector classes without being accused of creating an unregistered fragment identifier scheme for lots of media types.

So, my immediate question is whether this PR gets us to acceptable point for FPWD while we debate whether fragment identifiers are needed at all (which may depend on PWP developments)? There was some concern about taking the fragment identifier section out altogether without further, potentially lengthy consideration.

[iherman]

As I see it, other Selectors involving multiple resources (currently Span Selectors and Multi Resource Selectors) are dependent on availability of Embedded Resource Selectors, so I would not want to replace the ERS with a fragment id as it would introduce a modeling complexity for those other two selectors and generally splinter the modeling approach overall.

You are right. The fragment ID would not replace the ERS, "just" provide an alternative formulation. And that is fine.

• unrefined Embedded Resource Selectors (which would simplify greatly)
• refined & unrefined Embedded Resource Selectors (much less simplification)
• any of the 3 new Selectors which are meant to work with collective resources like WPubs and PWPubs (what I do in this PR).

If I do have the (unrefined) ERS as a fragment, I can use any selector directly. E.g., example 13 would become something like:

{
  "source": "https://dauwhe.github.io/html-first/MobyDick.wpub#ERS(https://dauwhe.github.io/html-first/MobyDickNav/html/c001.html)",
  "selector": {
    "type": "CssSelector",
    "value": "#elemid > .elemclass + p"
  }
}

Just as we would not provide a fragment ID for the CSS selector in general (let alone refinement) I am not sure why we would provide this selection as a fragment, whereas we would not provide a fragment for, say,:

{
  "source": "https://dauwhe.github.io/html-first/MobyDickNav/html/c001.html",
  "selector": {
    "type": "CssSelector",
    "value": "#elemid > .elemclass + p"
  }
}

Hence my uncomfortable feeling for your second option, for example (and the same for the third option)

So, my immediate question is whether this PR gets us to acceptable point for FPWD while we debate whether fragment identifiers are needed at all (which may depend on PWP developments)? There was some concern about taking the fragment identifier section out altogether without further, potentially lengthy consideration.

Fair question. I am fine with this PR if the choices you outlined above were added in the editorial note, making it clear that what we have here the full, third option. And making it clear that another alternative is to pick option one, have a fraction defined ERS and maybe show the example I have put in this comment as to what it would be useful for.

(Probably worthwhile put your reasoning into an issue rather than leaving it in the PR which will be closed as soon as you merge.)

[BigBlueHat]

I'll follow @iherman's recommendation on the overall PR.

So, my immediate question is whether this PR gets us to acceptable point for FPWD while we debate whether fragment identifiers are needed at all (which may depend on PWP developments)? There was some concern about taking the fragment identifier section out altogether without further, potentially lengthy consideration.

For this, though, I'd prefer we take out the fragment identifier section altogether as this is (and would be) the wrong document to define it in. It will need to be created and registered relative to a media type, and since this one doesn't define one, I'd recommend we leave it out of this and focus just on the new selectors being proposed--rather than also tangling in complex fragment identifier related issues (that might confuse choices we make).

Thanks for your work on this, @tcole3!

[iherman]

@BigBlueHat,

It will need to be created and registered relative to a media type, and since this one doesn't define one, I'd recommend we leave it out of this and focus just on the new selectors being proposed--rather than also tangling in complex fragment identifier related issues.

That makes sense. But being silent is may not be really useful either, so, for the time being, I am fine keeping whatever we decide to keep.

There is already a note making it clear that the fragid is bound to the question of defining a media type (or not), and we can also add a sentence there referring to the fact that this section may have to move to wherever the registration is formally defined.

But I take the point on the fact that we should focus really on the new selectors we define, and this issue makes the document even more complex. I think that by reducing the fragid to the ERS (ie, option 1 of @tcole3), the complexity would be greatly reduced, because that becomes a very simple fragid. If we do that, and we hint to the fact that we can consider defining a more complex set of fragid-s for the other two (rather than putting in everything as it is now) then the result may be more palatable...

[tcole3]

Per discussion on 27 November WG call, I am closing this PR and will generate a new PR that removes the separate section on fragment identifiers and adds a unrefined ERS-only fragment identifier scheme to the ERS definition with the same caveat that if we end up with no separate media-type for PWP then we will delete all mention of fragment id.

I will also add my comment above into issue #6 and relocate in the current locator draft the reference to this issue (which is in the section to be deleted).

Lastly I will add editor note to Span Selector definition, saying that if compelling use case(s) emerge a more complex frag id scheme could be added back to this document to include not only ERS, but also Span Selector and Multi Resource Selector potentially adding also the ability to refine all 3 selectors - i.e., we could resurrect something like what this pull request tried to do if we do define a PWP media type and it turns out that there are User Agents who would really rather have fragment ids and not json.