Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should string really be a MUST for non-HTML content? #101

Open
voxpelli opened this issue Jul 25, 2017 · 0 comments
Open

Should string really be a MUST for non-HTML content? #101

voxpelli opened this issue Jul 25, 2017 · 0 comments

Comments

@voxpelli
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant