[tb]So unless I'm reading incorrectly, the mf2 h-entry spec seems to imply that you would only ever have a single value for in-reply-to, like-of, repost-of, and bookmark-of. I'm trying to normalize 'first value only' vs 'accepts multiple values' in my parsing/database schema
[tb]Also (and totally tangential question to the first one) — if I have a video post with multiple `u-video` s that are just different derivative encodings, do I put the sizes for each of them into `p-size` and just expect clients to interpret those in parse order as associated to their respective `u-video` URLS? (And similarly for `p-duration` if the `u-video`s are actually different clips from each other)
ZegnatCurrently there is no system for linking properties together. You would need to create a different h-object for that. But an h-entry can contain any number of properties and duplicate properties as far as mf2 is concerned. Whether consumers like Micropub and Microsub support that is up to each implementation.
[tantek][tb], jf2 is much smaller subset of mf2json and still quite in flux (eg spec is not up to date with what implementations are doing, might need to do a popup on that)
[tantek]h-entry should not have an opinion about singular or plural properties like of those you mentioned. Could you quote from the spec what gave you the impression of “only ever have a single value”?
[tb]• [tantek] I think when reading through the core properties http://microformats.org/wiki/h-entry#Core_Properties here, I took the singular vs plural description at face value (i.e. *`p-category`* - entry categories/tags as talking about potentially having multiple and *`u-url`* - entry permalink URL talking as a singular value)