[spec] What to do of fragments when there is a redirection

[Luke Emmet]

On 23-Dec-2020 22:22, William Orr wrote:
> Wouldn't this be dependent on the other discussion of IRIs, since 
> gemtext can have arbitrary unicode? Also would require clients to NFC 
> normalize the prefix/heading lines before doing the matching.
>
> 23 dic. 2020 19:40:00 John Cowan <cowan at ccil.org>:
>
>
>
>     On Tue, Dec 22, 2020 at 7:51 PM Philip Linde
>     <linde.philip at gmail.com <mailto:linde.philip at gmail.com>> wrote:
>
>         It might be more robust to define the fragment as referring to
>         the
>         first heading line that has the fragment content as a prefix, but
>         that's still prone to break with document changes.
>
>
>     Even HTML fragments break if their referents are deleted.  Nothing
>     is completely immune.
>
>         For a good balance, one might have the fragment be a an exact
>         match of
>         the heading line you refer to
>
>
>     That's reasonable, but I think a prefix match would suffice; that
>     way you aren't tempted to make headings overly short in order to
>     keep fragments small.
>

How about this scheme:

  - use the full text of the headings only as index points, encoded in a 
simple way and truncated for simplicity

The psuedo code would be:

    marker = take-left (base64 heading) 12

Example, imagine a document having headings and we want to calculate a 
match or a lookup for some heading. Lets say heading text is:

"# This is a heading"

the marker is therefore "IyBUaGlzIGlz"

So a link to that heading would be:

gemini://server/path/to/end/point.gmi#IyBUaGlzIGlz

(or some other value, doesnt have to be 12, but feels about right)

this would have the following advantages:

1. Content-addressable, so quite robust to insertions, deletions 
elsewhere in the document, whereas the offsets/counting schemes are less 
robust. Although as others have pointed out, there is no completely 
robust mechanism that is tolerant of any change to the document.

2. Not too long, but long enough so there is a reasonable likelihood not 
to have too many false positive hits in any document, generally.

3. Easily calculated and fast

4. UI is simple - select the heading (e.g. right click or whatever the 
equivalent gesture would be in your client), and have the client tell 
you the corresponding marker

5. Works with unicode heading content

6. URL friendly

Or maybe some sort of variant on something like this.

Or maybe we just live without them - we can always return to this some 
other time if there really is a pressing user need. Is there really a 
requirement really for this yet?

  - Luke