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

[Dave Crocker <[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.

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

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

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.

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.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net