Closed dret closed 7 years ago
dret
commented
7 years ago i am slightly in favor of dropping support for the * syntax and simply fold this into one property. this means some information loss in some cases (when both title and title* are present), but results in a more succinct representation in JSON.
dret
commented
7 years ago suggested resolution for this topic (based on the general pattern proposed as resolution for #74):
without schema knowledge it is not possible to recognize RFC 5987 style attributes, except when the x* syntax is actually used.
the non-asterisk variants of these attributes therefore are represented according to the general rules laid out in #74.
the asterisk variants use a micro-syntax for encoding and optional language tagging. RFC 5987 allows them to be repeatable (even though RFC 5988bis makes title* non-repeatable).
therefore, asterisk variants are represented by arrays.
each array value is an array with one required string (the attribute value), and one optional string (the optional language tag). no additional values are allowed.
this requires processors mapping from the native syntax to interpret the character encoding that the native syntax supports, and transcode the value accordingly. language tags also have to be extracted from the microsyntax and represented individually.
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"]] } ]
dret
commented
7 years ago the current draft does not quite capture the resolution. it requires title* to be an array instead of an array with an array. will fix the draft to keep in line with the proposed structure:
native: <http://example.org/>; rel="next"; title*="UTF-8'de'n%c3%a4chstes%20Kapitel"
JSON: [ { "href":"http://example.org/", "rel":"next", "title*":[["nächstes Kapitel", "de"]] } ]
dret
commented
7 years ago fixed in updated -01 (and published according to #81)
67 and #74 both are relevant when it comes to deciding how to represent RFC 5987 style target attributed. we could join them into less complex model (avoiding the
x/x*names and simply go with"x"in JSON), or we could maintain the complexity/expressivity of the native syntax and RFC 5987 in order to retain everything RFC 5988bis can represent.