Re: [apps-discuss] New I-D: text/markdown Media Type - draft-seantek-text-markdown-media-type-00

[Ned Freed <[e-mail]>]

> On 7/9/2014 4:25 PM, Carsten Bormann wrote:
> > 1) define tags, one for each of the extensions and willful violations ("flavors”).
> >    The tags defined by pandoc could serve as a starter set here.
> > 	http://johnmacfarlane.net/pandoc/demo/example9/pandocs-markdown.html
> >    Add an IANA registry with “specification required” policy.
> > 2) mark an instance by the set of tags that apply to it (or, possibly could apply to it)
> > 3) “Accept:” instances by the set of tags that can be processed (i.e. any subset is acceptable).
> >
> > If the registry has numeric values added, the sets could be efficiently indicated as a numerically encoded bit set.
> > (Otherwise the tags get a bit unwieldy, e.g. gfm = pipe_tables, raw_html, tex_math_single_backslash, fenced_code_blocks, fenced_code_attributes, auto_identifiers, ascii_identifiers, backtick_code_blocks, autolink_bare_uris, intraword_underscores, strikeout, hard_line_breaks.)
> >
> > So this doesn’t seem too hard to do.
> >
> > Worth it?


> The goal here is to have the correct software processing the data.

That's one goal of media types, and the one associated with email. But
it isn't the only goal. The other obvious one is that of type label for
stored objects.

In the case of markdown, as previously stated, it's probably better for an
email client sending markdown with the intent of displaying it the result
immediately at the receiving end to use it as an input format only, and to
convert it to text/html prior to sending.

> So, there is a requirement to 'dispatch' to the correct code and a
> requirement to hand it useful parameters.

It falls short of a requirement in this case.

> If parameters are used for dispatching to unrelated code, then the
> question is why that wasn't better achieved with a media-type registration?

Because 20+ years of expereience say that wan't happen. Indeed, despite having
been around for quite a while, I don't believe there's a registration for
anything identified as a markdown variant.

But let's suppose for a moment that this time things are different, that
people will rush to register all the variants because, well, I don't
know why they would, but let's suppose.

What would the likely outcome of this be? If existing handling tables for
various "groups" of media types are any indication, the likely outcome will be
that all of the types (at least the ones people bother to put in the table,
which is another issue) point at a single, common handler, which then does
whatever. The odds of a proliferation of separate handlers in order to handle
minor incompatibilites a bit better seems highly unlikely. For one thing think
about the increase in code and associated vulnerabilities this would cause.

> Again, my reading of the discussion here is that the 'variants' are
> incompatible. I take that to mean that each uses a different code base.

Yes, the variants are, in the strict sense, incompatible. But there's a broad
swatch of features and functionality that are generally supported by all of
them. And more to the point, even when dealing with truly incompatible
handling, the nature of the format is such that something sensible, abeit
suboptimal, tends to happen even when the wrong processor is used.

But you need not take my word for it. The Babelmark2 tool lets you compare
how 20+ different tools handle the same input:

   http://johnmacfarlane.net/babelmark2/

I think you'll find that while it's easy to construct inputs that produce
different outputs, creating inputs that work fine in one variant but produce
garbage in another is a lot more difficult

Indeed, I find the biggest annoyances by far to the limitations of the format
itself. Which is as it should be.

> If, instead, there is a common code base that gets 'tuned' by something
> like a flavors parameter, then it makes sense to use a parameter.

To the extent that this matters, I think this is the best outcome we
can hope for in this case.

Finally, I cannot help but once again note that this has a lot more to do with
incomtible engineering aesthetics than anything else. People here are writing 
like "incompatibility" in this context means the same thing as it does for a
protocol or a format carrying critical protocol-related information. Sure, when
protocols or the formats they depend on are incompatible, things tend to go
badly wrong. But that's not applicable here.

				Ned