text/markdown effort in IETF (invite)

[Aristotle Pagaltzis]

* Sean Leonard <dev+ietf at seantek.com> [2014-07-09 22:10]:
> Markdown has no way to communicate the character set in the document
> (other than the Unicode Byte Order Marks, which is a generalized
> property about text streams, not specific to Markdown)--and it would
> be counterproductive to invent one. So that is a perfect example of
> relevant metadata. And the second one, is how to turn it into
> something else that the author wants. If it's not communicated, it's
> going to be implied. Implied means "guessing" and likely "guessing
> wrong".

Yet guessing wrong is largely without consequence.

There are really no syntax features that affect the document’s rendering
non-locally. If part of a document is written with unsupported syntax,
only that part will render incorrectly, but the other parts will come
out fine.

And there are no large overlapping surfaces among the syntaxes of the
various extensions (esp. those for very different document features),
which makes unsupported syntax unlikely to appear to have been intended
to be rendered as some completely dissimilar feature.

So you will get a document that differs from the author’s intent in some
way. But it will be clear *where* the differences are and you will still
get all of the data in *some* form, quite possibly fully intelligible if
not pretty.

And because of the primary goal of Markdown to be human-readable in its
source form, there is always an easy and cheap last resort: view source.

Bottom line, misrendering a document due to wrong choice of flavour is
annoying but inconsequential, due to the very nature of Markdown.

Therefore the flavour parameter ought to be considered nothing more than
loosely informative, and the processor should just render the document
to the best of its ability regardless of the flavour specified. It MAY
use the parameter value to adapt to the document, in RFC 2119 lingo, but
ought not be bound by it.

Furthermore, an absent flavour parameter ought to mean that the flavour
is unspecified, not that it is any particular default flavour; i.e. the
choice of flavour in that case ought to be up to the processor.

Lastly, the spec should mention (as informal guidance to implementors)
that applications containing Markdown processors which have any chance
of being exposed to source documents of unknown flavour should, if at
all possible, provide a means for the user to view the source Markdown
document in unformatted form.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>