> On Jul 9, 2014, at 3:07 PM, Michel Fortin <[email protected]> wrote:
>
> I sure wish things would be simpler. But as things are now, I have a hard
> time identifying what "flavor" could mean. Should "Markdown.pl-1.0.1" be a
> flavor on its own?
Perhaps it would be better to have *two* optional fields:
- A "processor" field, as in `processor="Markdown.pl-1.0.1"` or
`processor="Pandoc-1.12.4.2-nostrict", which indicates that the sender was
using (that program) to view the output and was satisfied with it. This could
be included whenever known, and hopefully *not* relied upon by the recipient,
but could provide useful clues in some cases where the recipient *has* to
decide how to interpret something.
- A "flavor" field consisting of zero or more alphanumeric tokens, separated by
"+" or "," or some such, declaring well-understood deviations from, or
extensions to, the original standard. Not as a completely exhaustive list (you
don't have to be able to indicate that your processor has, say, special syntax
for animated gif backgrounds if no one else can use that anyway), but simply to
promote better interoperability, to be interpreted as "the text contained
herein supports basic markdown, plus *at least* X and Y and Z capabilities".
Include some useful things like:
- "nofill" (hard returns should be obeyed rather than joining lines - this
would clarify that "two github flavors" situation),
- "tables" (supports some agreed-upon "least common denominator" table
syntax),
- "footnotes" (similar but for footnotes),
- "fencedcodeblocks" (you get the idea),
- "titleblock" (text lines before first blank line are some sort of
metadata and shouldn't be displayed to casual viewers),
- "restrictunderscores" (mid-word underscores are not to be interpreted as
starting/ending emphasized or strong text)
The idea being, merely having the "text/markdown" content type would not
guarantee anything beyond "well, it's *some* sort of markdown flavored text",
while specifying one or more of the attributes in the "flavor" field would
indicate "yes, you can assume that if something looks like an X, it *is* an X"
(where X is something from the list above). It doesn't necessarily mean you
*will* find, say, a table, in the text, merely that if you see something that
looks like a table, it likely is.
This way, senders can give a series of hints to make their text more clear to
parse, using the "flavor" attribute, and can also declare what processor they
were using to view/validate things on their end, in case the recipient feels
they simply must know precisely how to interpret the text (at which point it's
up to them to decide what, if any, conversion or special handling is
necessary). And a recipient wouldn't need to consult an exhaustive list of
processors, but simply look at the flavors attribute to see if it recognizes
anything there as a useful hint (and render everything else naively).
So, you might have: content-type="text/markdown" flavor="tables+titleblock"
processor="floobity-1.2.3"
We'd need an agreed-upon list of, "ingredients", to put in the "flavors" field,
but, again, you wouldn't want to exhaustively list every variant of every
extension that any markdown-ish processor has ever come up with, only perhaps a
dozen cases to cover the most common extensions (if you need to be more
exacting, go consult the processor field and take matters into your own hands).
Does this make sense to anyone else? (I probably should have gone to sleep a
long time ago.)
Cheers,
Carl Jacobsen
_______________________________________________
Markdown-Discuss mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/markdown-discuss
