how to handle the repeatability of hreflang

[dret]

given the current (-00) design of the JSON representation, hreflang cannot be always represented in JSON. the reason is that hreflang can be repeated as a target attribute and a link parameter in the native serialization, but it cannot be repeated in the JSON serialization. the draft probably should at least mention this limitation, as there does not seem to be an easy way to represent this in JSON without complicating the JSON design a fair bit. an alternative would be to allow an array of values for hreflang, but then this becomes a special case. this is one example of how the abstract target attribute model of RFC 5988bis does not always work perfectly for a simple JSON model. https://github.com/mnot/I-D/issues/242 raises this as an issue about RFC 5988bis and suggests to alert target attribute designers about the fact that repeatable target attributes suffer from this limitation of the JSON syntax.

[dret]

one option here is to recommend that if a link in the abstract model of RFC 5988bis has more then one hreflang target attribute, then the recommended JSON serialization is to create as many links as there are hreflang attributes, each of these having one of the hreflang values. this is not great since it maps one link in the abstract model to multiple links in the JSON representation, but a least it means that no hreflang value has to be dropped. (note that this general procedure could be recommended for the problem discussed in #66 as well.)

[hvdsomp]

If I read RFC5899bis correctly, then it is not only hreflang but also extension attributes (both the token and token* variations) that can be repeatable because the spec leaves defining e.g. cardinality of attributes up to minters of attributes. The spec says:

This specification does not attempt to coordinate the name of target attributes, their cardinality or use. Those creating and maintaining serialisations SHOULD coordinate their target attributes to avoid conflicts in semantics or syntax, and MAY define their own registries of target attributes.

Somehow, I think this makes this issue even more significant.

[hvdsomp]

I think the task at hand can be summarized as:

• How to handle non-repeatable attributes of the token variant - solved
• How to handle repeatable attributes of the token variant (e.g. hreflang) - open
• How to handle non-repeatable attributes of the token* variant (e.g. title*) - open
• How to handle repeatable attributes of the token* variant (e.g. extension-attribute*) - open

Maybe we should close this Issue and open a new one with this task?

[dret]

as with #67, we can solve hreflang differently from the generic case (if we choose to) because we know the concrete attribute. we could propose a microsyntax (allowing hreflang="en de"), but that may overcomplicate things and i am wondering how often language-tagged links are indicating more than one language. i am in favor of ignoring multiple hreflang, and saying that for the JSON syntax, the first hreflang value should be used, and the other are ignored/dropped. regardless of how we resolve this issue, we should document how hreflang gets handled specifically, in addition to defining what happens with extension attributes that follow the same pattern.

[asbjornu]

:+1: to ignoring multiple hreflang attributes and describing this in the I-D.

[dret]

On 2017-08-15 08:00, Asbjørn Ulsberg wrote:

👍 to ignoring multiple |hreflang| attributes and describing this in the I-D.

thanks for the vote. @hvdsomp took the opposite stance.

[hvdsomp]

Yeah, but then @asbjornu saw my #74 :-)

[dret]

suggested resolution for this topic (based on the general pattern proposed as resolution for #74):

• hreflang is repeatable and thus represented as an array. each occurrence of hreflang on a link in the native representation is mapped to one string in the value array.

• hreflang always MUST be an array (even though in practice there are probably very few links with multiple hreflang attributes on them).

[hvdsomp]

Total endorsement in light of overall solution proposed in #74