You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My understanding was that the intention of of the Micropub design was to allow extensions by making it possible to either return a value as a string right away or as a {"value": "Foobar"} and that the latter setup could be used if additional metadata needed to be added by extensions, such as if a language extension wanted to specify a "lang" key.
Similarly there has been brief discussions on whether it would make sense to experimentally extend Micropub with support for Markdown as a data format and that would require that an extension returns that data similarly to how HTML is returned, which isn't possible with the current wording that any content that isn't HTML MUST be returned as a string. (Eg. {"content": {"commonmark": "text"}} is one brainstorm of a format)
So: At a bare minimum it would be good to allow for non-HTML, non-plain text data to also be expressed as an object and it would be even better if also plain text data would be allowed to be expressed as an object in the form of {"value": "Foobar"}.
I know the standard is set now, but posting it here anyhow to get a discussion going and maybe, if this was never an intentional wording, one could publish an errata or something.
Just noticed in https://www.w3.org/TR/micropub/#html-content that whenever the content isn't HTML it's defined that the content
MUST
be a string.My understanding was that the intention of of the Micropub design was to allow extensions by making it possible to either return a value as a string right away or as a
{"value": "Foobar"}
and that the latter setup could be used if additional metadata needed to be added by extensions, such as if a language extension wanted to specify a"lang"
key.Similarly there has been brief discussions on whether it would make sense to experimentally extend Micropub with support for Markdown as a data format and that would require that an extension returns that data similarly to how HTML is returned, which isn't possible with the current wording that any content that isn't HTML
MUST
be returned as a string. (Eg.{"content": {"commonmark": "text"}}
is one brainstorm of a format)So: At a bare minimum it would be good to allow for non-HTML, non-plain text data to also be expressed as an object and it would be even better if also plain text data would be allowed to be expressed as an object in the form of
{"value": "Foobar"}
.I know the standard is set now, but posting it here anyhow to get a discussion going and maybe, if this was never an intentional wording, one could publish an errata or something.
/cc @aaronpk
The text was updated successfully, but these errors were encountered: