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: => gemini://gemi.dev/gemini-mailing-list/messages/005420.gmi
---
Previous in thread (55 of 99): 🗣️ PJ vM (pjvm742 (a) disroot.org)
Next in thread (57 of 99): 🗣️ Oliver Simmons (oliversimmo (a) gmail.com)