case 1 is a mix of case 2 and case 3, right? it requires "post-processing" of the microsyntax, because the value is repeatable, but the attribute is not.
i toyed with the idea of describing such a "mapping framework", but it seemed a bit overkill to me because there are not that many more specific cases than there are general cases.
1-3 seem to work well just describing case by case. 4 and 6 do have some overlap and that's the best candidate (but the current draft does have a section dedicated to describing this pattern, so that's sort of covered). 5 is also covered by a dedicated section in the current draft.

or did i misunderstand and this is just a summary write-up and not intended to go intro the draft? in that case no issue here: this covers the solutions described in the individual issues, so we're all good.

@dret @hvdsomp I did define much of a mapping from HTTP headers to and from JSON at one point, and may well revive it depending on how we decide to handle hints in JSON Hyper-Schema: json-schema-org/json-schema-spec#296

@dret thanks! That looks extremely relevant :-) I really need to dig through the draft list more often and in more detail.

@handrews:

I really need to dig through the draft list more often and in more detail.

No digging required. Just sign up for the relevant announcement list(s). :)

@dret Allow me to clarify what I tried to do with the above:

• Make the logic behind the choices made for the serialization explicit

• Provide an overview of the JSON serialization as it currently stands

• Following a suggestion you made a while ago when we were discussing the structure of the I-D, describe the JSON serialization following the structure of RFC5988bis:

1. CASE 1 == Section 3.3. Relation Type (note that "rel" is not an attribute)
2. CASES 2 through 4 == Section 3.4.1. Serialisation-Defined Attributes (the various cases pertain to the possible variations in the dimensions repeatability/non-repeatability and token/token*)
3. CASES 5 and 6 == Section 3.4.2. Extension Attributes (the various cases pertain possible variations in the dimension token/token*; the dimension repeatability/non-repeatability does not play here because de-facto all is treated as repeatable)

• I did not come from the perspective of how native links needs to be mapped to the JSON links. The reason being that the description provides an overview of the serialization per se. And that I assume JSON will also be used just by itself, without there ever being a native representation. Then again, I do very much agree that it would be good to include a description of the mapping in the I-D because there obviously will be cases where mapping will need to happen. Therefor, I did copy/past some wording you had in other Issues with that regard. Personally, I do however think that describing the JSON serialization and the native/JSON mapping are different things and - IMO - would not necessarily have to be described in the same section of the I-D.

I checked whether/how the above CASES 1 through 6 could be handled using the syntax proposed by @stain in a comment in #89. The result is below.

Comments:

• It seems to me that all CASES can be covered by the syntax proposed by @stain. Double check welcome.
• I like how the syntax rather elegantly expresses a set of links, i.e. a graph.
• I love how the syntax always makes the link anchor explicit. This makes linkset documents more stand-alone/portable. In the serialization of the current I-D, anchor is optional but all examples make explicit use of it. This suggests that provision of the anchor is deemed important.
• The rev (as opposed to rel) links can be addressed by directly expressing the inverse link, i.e. using the target of a rev link as anchor.
• I see quite an advantage in that the syntax can be used "as is" in basic JSON scenarios and in JSON-LD scenarios by adding appropriate context (inline or via Link header).
• In the JSON-LD case, I see an issue with so-called extension relation types, i.e. relation types not registered with IANA. In order to avoid misinterpretation, it seems those must be expressed as URIs in the JSON-LD case. That's also what @stain did in his example to avoid mapping an extension relation type to an IANA baseURL when applying context.
• In the below, I did not use the approach with the embedding linkset as proposed in #103 but I am in favor of it for the reasons explained in that issue.

Here goes, assuming the link anchor is http://example.net/bar:

CASE 1

native: http://example.org/; rel="start";
JSON as per current I-D: [ { "href":"http://example.org/", "rel":[ "start" ]} ]
JSON as per Stian: [ { "anchor":"http://example.net/bar", "start":{"href":"http://example.org/"} ]

native: http://example.org/; rel="start home";
JSON as per current I-D: [ { "href":"http://example.org/", "rel":["start", "home" ] } ]
JSON as per Stian: [ { "anchor":"http://example.net/bar", "start":{"href":"http://example.org/"}, "home":{"href":"http://example.org/"} ]

Case 2:

native: http://example.org/; rel="start"; title="this"
JSON as per current I-D: [ { "href":"http://example.org/", "rel":[ "start" ] , title:"this"} ]
JSON as per Stian: [ { "anchor":"http://example.net/bar", "start":{"href":"http://example.org/", "title":"this"} ]

Case 3:

native: http://example.org/; rel="next"; hreflang="en de"
JSON as per current I-D: [ { "href":"http://example.org/", "rel":"next", "hreflang":["en","de"]
JSON as per Stian: [ { "anchor":"http://example.net/bar", "next":{"href":"http://example.org/", "hreflang":["en","de"] ]

Case 4:

native: http://example.org/; rel="next"; title*="UTF-8'de'n%c3%a4chstes%20Kapitel"
JSON as per current I-D: [ { "href":"http://example.org/", "rel":"next", "title*":["nächstes Kapitel", "de"] } ]
JSON as per Stian: [ { "anchor":"http://example.net/bar", "next":{"href":"http://example.org/", "title*":{ "@value": "nächstes Kapitel", "@language": "de" } ]

Case 5:

native: http://example.org/; rel="start"; param="x"
JSON as per current I-D: [ { "href":"http://example.org/", "rel":"start", "param":["x"] } ]
JSON as per Stian: [ { "anchor":"http://example.net/bar", "start":{"href":"http://example.org/", "param":["x"]} ]

native: http://example.org/; rel="start"; param="x y"
JSON as per current I-D: [ { "href":"http://example.org/", "rel":"start", "param":["x y"] } ]
JSON as per Stian: [ { "anchor":"http://example.net/bar", "start":{"href":"http://example.org/", "param":["x y"]} ]

native: http://example.org/; rel="start"; param="x"; param="y"
JSON: [ { "href":"http://example.org/", "rel":"start", "param":["x","y"] } ]
JSON as per Stian: [ { "anchor":"http://example.net/bar", "start":{"href":"http://example.org/", "param":["x","y"]} ]

Case 6:

native: http://example.org/; rel="next"; x*="UTF-8'de'n%c3%a4chstes%20Kapitel"
JSON: [ { "href":"http://example.org/", "rel":"next", "x*":[["nächstes Kapitel", "de"]] } ]
JSON as per Stian: [ { "anchor":"http://example.net/bar", "next":{"href":"http://example.org/", "x*":[{ "@value": "nächstes Kapitel", "@language": "de" }] ]

just wondering: don't we have any examples with extension link relation types (i am just looking at the examples of case 1-6)? if that's the case, we should add one.