Repository navigation
Support link relations #44
Description
Activity
I like the idea, but I would suggest not using the property name
links. My concern is that it could be misinterpreted that you're supposed to put all links on the page into that array. The Microformats2 JSON format has been using the propertyrelsfor this purpose for many years. That way it's mostly self-descriptive as to what you're supposed to put in it.Have only 4 top-level keys. Values of keys "title", "description", and "comment" are strings. A new key "links" (or "urls" if you prefer) is an object. Each key of "links" is a relation (IANA or custom URI relation). Values can be strings (must be URL), array of strings, object with required "href" and optional other fields e.g. "title", or an array of such objects. "feed_url" becomes "self", "home_page_url" becomes "top" or "start", "items" becomes "item".
Now you have a very simple format that is extensible and hypermedia-compatible.
one more data point: HAL uses a
_linksmember for the same purpose. http://stateless.co/hal_specification.htmlThis proposal appears to be one of the most important current proposals for JSON Feed, as it would allow to allow further features and custom data insertion.
I have already linked to this proposal from five different proposals, including one of my own, as it covers many features that are currently being proposed.
I advise to be as much as conformative with The Atom Syndication Format (RFC 4287).
Additionally, link relations would enable navigational directives.
And link relations would further facilitate future features merely by changing the value of attribute "rel", as I did with project Rivista Voyager.
See demonstration of navigational directives at.
https://journal.woodpeckersnest.eu/posts/2024-08-01-establish-your-i2p-site-in-five-minutes/
https://journal.woodpeckersnest.eu/posts/1270-01-01-havamal-ii/
Project source code.
This resource might also be helpful for the argument of @voxpelli.
HTML4 definition of the 'rel' attribute. Here are some additional values, each of which can be used or omitted in any combination (unless otherwise noted, and except where prohibited by law) and their meanings, symmetry, transitivity and inverse if any. Please see the XFN home page for more information about XFN.
We might want to consider to add more attributes than those that are offered by The Atom Syndicationn Format and SGML (HTML4).
The Atom Syndication Format offers "href", '"hreflang", "length", "rel", "title", and "type".
https://rfc-editor.org/rfc/rfc4287#section-4.2.7
SGML (HTML4) offers "charset", "href" "hreflang", "name", "rel", "rev", and "type"
https://w3.org/TR/html401/struct/links.html#adef-name-A
However, it appears that SGML (HTML4) is missing an attribute "media" for CSS, so attribute "type" is utilize to compensate that supposed lack.
type="text/css; media=screen"
Another attribute which I deem to be missing is "description" to describe a source, and it can be compensated for The Atom Syndication Format by utilizing the same structure for SGML (HTML4) with element "title".
title="The Atom Syndication Format; desc=The specification RFC 4287"
I think that specifying attributes "media" and "description" be useful; of course, it is always possible to add custom attributes, if a developer wishes.
There are lots of link relations that have been defined and which can be used to add additional metadata to links and link contexts and link relations have shown to be a powerful way to easily and independently extend formats and have them interact with other specifications through a shared basic semantic that enables it to support those other specifications without having to know any specifics about those other specifications.
Link relations are supported in HTML, Atom, HTTP (through Link-header), RSS (by using the Atom namespace) etc
The HTML spec points to the Microformats link relation registry for it's values: http://microformats.org/wiki/existing-rel-values
Historically there has also been a Link Relations spec that unified Link Relations across standards: https://tools.ietf.org/html/rfc5988
I would suggest supporting this at both feed level and item level through something like:
The rel-payment mentioned there gained pretty good traction among mobile podcast clients that wanted to allow automation of sending of donations to Flattr.com after someone had listened though an entire podcast. It even got Instacast rejected from the app store. It truly showed the power of link relations when I, working at Flattr at the time, could just decide to utilize an existing link relation in places that allowed link relations and that way, without having to convince any specific feed format or feed parsers to add specific support for payment links, get a standard conformat format for donation links – a format that later eg. Gittip could pick and and support as well and more generic donation mechanisms be built around.
Allowing link-relations enables others to extend this format in similar ways in the future – adding capabilities that we either can't imagine right now or that are so obscure that we never will really care about it, but a minor sub-group of the community will feel that it adds a lot for them.