Small normative issues

(Edit: copypasta from the bottom: "this has gotten _way_ too long... whoa. Let me know if you want me to break this down into separate issues or add GitHub todo checkboxes or something")

Some questions I had reading through the draft that might affect normative language:

Section 4.2.2 states that "conforming consumers must not halt on any unrecognized properties or types" but AFAICT publishers are required to use JSON-LD's extension mechanism anyway right? So what's the point of this requirement? Actually now that I write it out I'm guessing it's in case consumers don't want to do full-blown JSON-LD; is that it?

> Conforming consumers may present conforming documents to a user on screen, in print, in audio format, or using other presentation mechanisms.

This kinda seems to be the spec overstepping its bounds and getting into UX territory...

> Conforming consumers must faithfully translate the information represented in conforming documents into these other formats or media.

Not sure how this requirement is useful, practically speaking. Is it to prevent bad actors? They'll do it anyway.

The "Reserved Keyword" section's language on the `references` property is confusing. Maybe it's just me not having a strong CS/data structures background but mentioning that it's an associative array threw me and I think it'd be a lot simpler to just say "`references` is a JSON object which maps external URLs to their corresponding representations. The JSON object's keys MUST be URLs used as `id`s of sub-objects in the document. The values MUST be JSON objects." The bit at the end requiring it to be serialized as an associative array is also confusing - I think that should be dropped in favor of more clearly spelling out how these objects are composed.

`html` is specified as a reserved keyword, but what if the vocabulary (or at least, its typical serialization) isn't HTML-based?

It's unclear to me what the difference between `text` and `value` is. Also, `value` is "presumed" to be text/plain but it seems unfortunate that AFAICT you can't tell for sure?

`@context` apparently has an inferred value if it's not there, but it's never actually stated what this inferred value is.

According to the "Post Properties" section if a property references another object it may be serialized as the "unique identifier" where the object can be found. It's unclear to me what "unique identifier" might mean. URI?

Looking at 5.2.3 Example Post 1, I see a `content` property. IIRC this is an mf2 thing, but it's unclear to me how this interacts with the `text` keyword. Does this make the `text` keyword unnecessary?

The example in 5.4 HTML Content is _very_ confusing. `content` is a property that comes from the vocabulary but somehow it magically became an object instead of a string? And this object uses reserved keywords? The interaction here needs clarification.

"Using References" says that `references` should be used whenever a referenced object is "defined authoritatively in some other location." I can't quite pin it down but this makes me uncomfortable; after all, aren't all JF2 documents inherently non-authoritative? Maybe the implementer just has to use their best judgement, or I don't have enough implementation experience to realize when this is obvious, but thought I would bring it up just in case.

Parsing implementations apparently SHOULD fetch data from the authoritative source instead of using `references` but this makes `references` seem kinda pointless. I think this requirement should be amended so that it only applies if the implementation really desires authoritative data. This is made more complicated by the fact that often authoritative sources are HTML so if the implementation only has a JSON parser, not an HTML parser, they basically _have_ to rely on `references`.

It appears to my untrained eye that the "Deriving the Syntax" section doesn't actually say anything normative about how to transform from the mf2 JSON to the simplified version. Am I correct in thinking that they're both valid JF2 documents, and the simplified version is just whatever transformations the publisher finds appropriate (e.g. transforming single-item arrays into strings)? If so, that should be explicitly called out because otherwise I feel I'm missing instructions or something.

The JSON-LD Consideration section is kinda frustrating. E.g. it says you may need to "modify serialization slightly" but doesn't specify how. Definitely understand if there isn't a lot to be done about this, just thought I would mention it.

Stopping here as I gotta do some other stuff before the morning, and because this has gotten _way_ too long... whoa. Let me know if you want me to break this down into separate issues or add GitHub todo checkboxes or something.

Start with the draft sections named in the issue: 4.2.2, Reserved Keyword, 5.2.3, 5.4, Using References, Deriving the Syntax, and JSON-LD Consideration. Separate the many normative-language questions into focused decisions, then update the draft so each behavior and term is explicitly defined and the examples agree with it.

Written by the indexing model from the issue text.