[SPEC] Backwards-compatible metadata in Gemini

[Oliver Simmons]

On Mon, 22 Feb 2021 at 10:18, Stephane Bortzmeyer <stephane at sources.org> wrote:
>
> Why? These people would only see the text at the end of the line, not
> the 'data:' link itself.

Some clients show the links, most have an option to display it if they don't.
Myself I like to have them shown so I know where I'm going.

> * What set of characters in the key (except the colon, of course)?
> LDH? ASCII letters or Unicode?

Gemini follows UTF-8/Unicode encoding everywhere else, so sticking to
that makes sense.
A "best practice" will be to stick to regular ASCII characters if possible.

> * What about the value? Completely unstructured and therefore
> unparsable? Your own example for "last-edited" is useless for programs
> since it does not fit any known standard for dates.

last-edited was just a random example, I wasn't trying to propose keys
or values.

> * Will we need a list of standard keys, to avoid some people using
> "last-modified", others "last-edited" and others "last-change"?

A list of common keys/values should be a thing, without out it the
metadata will be really impractical for any clients to use and will
degrade into meaningless junk.
However this should NOT be a part of the spec, anyone can use any
keys/values they like, but a list of commonly used & recognised by
client should be kept.

OSM has a nice semi-related quote for this:
>From https://wiki.openstreetmap.org/wiki/Any_tags_you_like:
> Feel free to invent new tags! Though it is not "feel free to ignore existing tagging schemes and start marking pharmacies with unicorn=parking_lot".
(tags being key/value pairs)