[SPEC] Backwards-compatible metadata in Gemini

Oliver Simmons oliversimmo at gmail.com
Wed Feb 24 19:18:54 GMT 2021


On Wed, 24 Feb 2021 at 19:07, John Cowan <cowan at ccil.org> wrote:
>
> Part of the problem there is without a signal like "=: " that isn't likely to be ordinary content, it's easy to get confused.  Consider this:
>
> =====CUT HERE=====
[...]
> =====CUT HERE=====
>
> It's obvious to a human that the last four lines are metadata and the rest is content.  But a metadata processor's job is much simplified if the last four lines are:
>
[...]
>
> That makes it clear that "Longaville", for example, is not a key.  This is Lars's proposal.  To it I add the convention that a link name beginning with =: contains metadata applicable to the linked resource.  And that's it.  I don't see that this is particularly more extensible than the "unmarked key-value pairs at the end" convention.  As for readability, if we can get used to seeing "=> " as a link, we can get used to "=: " as metadata.
>

It appears you missed an important part of the key/value form: the toggle line.

A toggle line would be used (I suggested ^^^, but there may be a
better one), and it would be enable-only, there is no toggle off.
(extra toggles must be ignored by clients)
This enforces putting it at the end of a file, and prevents mixing it
with regular content, as being able to mix it would make Gemini
awfully easy to extend.
After the toggle the only acceptable lines would be either empty, or metadata.

Example:

# My lovely example
Hello, and welcome to example text.
=> /fooo Bar!
^^^
key: value
another-key: another-value

Here was my original email where I explained how I thought it would
work very roughly:
=> https://lists.orbitalfox.eu/archives/gemini/2021/005420.html


More information about the Gemini mailing list