Closed tcole3 closed 6 years ago
Two additional, editorial notes
As has been noted many times, we really need clear use cases for this.
My comment on the (otherwise closed) PR #15 remains: implementors have to do something fundamentally different than what they have at their disposal in a browser: while State
and Selector
implementations can rely on HTTP facilities and DOM implementations, respectively, implementing positions pushes them in a very different, possibly unchartered territory. If really necessary for strong use cases, we should indeed do this (and this PR is, technically, clear and clean for that!), but I am not convinced of the necessity.
I am not opposed to merge this PR and discuss afterwards, but a roll-back from it may be complicated, because the changes are spread all over the place. I would really prefer having a decision before a possible merge...
CC @GarthConboy @TzviyaSiegman @llemeurfr @rkwright
For admin: this PR is relevant for issue #9
I think I've addressed issues raised by Ivan's review of this PR.
While might still benefit from further wordsmithing, would like to merge as is (especially since there are already subsequent PRs pending). Will do so later today or tomorrow morning, unless there is objection.
I still have my doubts about side-bias, but I'm convinced there are non-annotation use cases for a clean way to reference position in a text or byte stream (rather than just a selection / fragment of content). Also think Position specifiers will be handy for refinement.
I will merge it, to make the discussion cleaner for others
Added a new kind of specifier for describing and identifying a position within a text or data stream. Changes are more extensive, but better isolated from existing Selector and State specifiers Still need real-world use cases, especially for side-bias.
Preview | Diff