Oliver Simmons oliversimmo at gmail.com
Tue Feb 23 15:31:56 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Tue, 23 Feb 2021 at 09:16, Lars Noodén <lars.nooden at gmx.com> wrote:
Some of this depends on what kind of metadata we are talking about.
Gemini is about transmission of information and
metadata is information. By document metadata I mean information
/about/ the document content.
Only data about the document should be allowed, and it should notmodify the document (i.e. no stylistic info).
=:[<whitespace>]<TERM><whitespace><METADATA>
which could look like this in the body, but would be up to the client as
to how it is dealt with. Left unprocessed, it would degrade gracefully
and be quite readable.
This syntax would allow for it to be placed anywhere in the document,which could enable it to be used to extend Gemini in unwanted ways,for example:
=: text-colour redI'm blue!=: text-colour blueI'm red
:)(this is a lame example, there are probably worse things it could do)
Placing it at the end of the file, which my format would enforce,makes this impossible.If it did change the file (which wouldn't be allowed) it would have tobe the entire file, making this harder.
Also, using space as the delimiter causes some issues, for example:=: author Oliver SimmonsA simple client might try to split on the spaces, which would splitthe name into two, using a colon or equals is more conventional forkey/value things, and avoid this problem (wanting to use : or = in akey or value isn't likely).
Again, by being included anywhere inside the body, there would be no
extra network calls.
Just pointing out that none of the three proposed formats do this,extension of the protocol is entirely out of the question.This is NOT like HTTP headers, it is strictly document metadata.
There should be no requirement as to what is in the metadata, which
terms are allowed, or what the terms mean. Any extension should say
only how terms may be included and leave the rest up to the capsule and
the client software.
100% agree