Re: [apps-discuss] Call for Adoption: draft-seantek-text-markdown-media-type

[Sean Leonard <[e-mail]>]

Just wanted to add some observations that I made at the APPSAWG presentation:

Quoting Ned Freed <[e-mail]>:

>> In article  
>> <[e-mail]> you write:
>> >-=-=-=-=-=-
>> >-=-=-=-=-=-
>> >
>> >The biggest issue seems to be that there are a whole bunch of *almost*
>> >compatible markups.
>> >
>> >I would offer one of two directions. One is to punt and do what the draft
>> >says - acknowledge incompatible dialects and ignore compatibility.
>
> See my previously posting on this topic. The "incompatibility" we're talking
> about here is being overstated.

Correct. All Markdown content is compatible with Markdown processors.

There is no concept of "valid" Markdown. A Markdown processor  
identifies magical sequences of characters (aka markup) and converts  
them to the formal markup. If the processor does not recognize it, it  
is passed through to the output. Markdown processors therefore rarely  
reject content for being invalid. Many Markdown processors are  
implemented as a series of regular expressions, or as an  
implementation of PEG (parsing expression grammar).

>
>> > The other
>> >is to define an official Markdown markup, presumably based on the  
>> Gruber Web
>> >site.
>
> Which would be counter to the stated goals of the format.
>
>> Another approach is to do what RFC 4263 did for text/troff.  There's a
>> process= parameter which gives the recipient a hint about which
>> subflavor of troff it is.  Their example is:
>
>>   Content-Type: text/troff ; process="dformat | pic -n | troff -ms"
>
> I had completely forgotten about text/troff. Variants of troff really are
> completely incompatible, to the point where attempting to process them in the
> wrong way results in total gibberish. So there is running code for  
> an even more
> extreme variant along these lines.

In my presentation, I rejected the flavor parameter, replacing it with  
variants (or rulesets) and processor. The latter parameter is  
semantically the same as the "process" and "versions" in text/troff  
(thanks!--I did not notice that), indicating that there is precedent  
for it. The main difference is that RFC 4263, those parameters are  
"human-readable"--in my proposal for text/markdown, the parameters are  
structured with identifiers that can be used by automated processes  
(i.e., without substantial human interaction).

See: https://tools.ietf.org/agenda/90/slides/slides-90-appsawg-6.pdf

-Sean