Re: text/markdown effort in IETF (invite)
On Jul 9, 2014, at 3:07 PM, Michel Fortin michel.for...@michelf.ca 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 Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
So, you might have: content-type=text/markdown flavor=tables+titleblock processor=floobity-1.2.3 That looks fine, but it has too many Combinations. I don't think Markdown should be standardised. It is, 1) Incomplete as compared to asciidoc 2) Self-Contradicting No general escaping 3) No formal grammar It is typically implemented by regexes. So unlike html, a bold phrase, can't span two lines. In the meantime you can standardise asciidoc, multimarkdown, wikicreole which are saner than the original markdown and they already have specs. Makrdown dubs its formatting on email conventions. That's not true, because email conventions are free-form ascii. Consider this email thread, for example. Cheers, Harsha ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
Le 10-juil.-2014 à 5:00, Sean Leonard dev+i...@seantek.com a écrit : I haven't tried it yet, but I suspect PHP Markdown is mostly encoding agnostic only for most encodings that preserve the US-ASCII range. That's what I meant by mostly encoding agnostic. It'll work with ASCII and most European encoding schemes because they are ASCII-compatible, but anything more fancy than that will have to be UTF-8. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
Le 10-juil.-2014 à 1:04, John MacFarlane j...@berkeley.edu a écrit : +++ Michel Fortin [Jul 09 14 18:07 ]: Fun fact: PHP Markdown is mostly encoding agnostic. It understands UTF-8 sequences but any byte that is not a valid UTF-8 sequence is treated as a character in itself. It's only relevant when converting tabs into spaces however, and only if you have non-ASCII characters before the tab. Small amendment: There are at least two places where the difference between utf-8 and latin1 matters: tab expansion (as you note) and reference links, since these are stipulated to be case insensitive. (Case conversion is sensitive to the encoding.) Like Markdown.pl, PHP Markdown will just treat non-ASCII characters in a case-sensitive way so in my case it doesn't matter. Also, if you want to compare characters in a case-sensitive manner, the most correct way to do it is to use the Unicode Collation Algorithm, not case conversion to lower or uppercase, because some characters can't round-trip (see [german ß]). Then you'll notice that unfortunately Unicode collation is locale dependent (because equivalent characters aren't the same in all locales, see the [turkish ı]). And then you'll realize there's not correct way to do it universally. [GERMAN SS]: https://en.wikipedia.org/wiki/ß [TURKISH I]: https://en.wikipedia.org/wiki/Turkish_dotted_and_dotless_I On Babelmark I see that cheapskate 0.1.0.1 understands the first link above -- good job! -- an no one understands the second one. http://johnmacfarlane.net/babelmark2/?normalize=1text=Also%2C+if+you+want+to+compare+characters+in+a+case-sensitive+manner%2C+the+most+correct+way+to+do+it+is+to+use+the+Unicode+Collation+Algorithm+--+not+case+conversion+to+lower+or+uppercase+--+because+some+characters+can't+round-trip+(see+%5Bgerman+ß%5D).+Then+you'll+notice+that+unfortunately+Unicode+collation+is+locale+dependent+(because+equivalent+characters+aren't+the+same+in+all+locales%2C+see+the+%5Bturkish+ı%5D).+And+then+you'll+realize+there's+not+really+a+correct+way+to+do+it.%0A%0A+%5BGERMAN+SS%5D%3A+https%3A%2F%2Fen.wikipedia.org%2Fwiki%2Fß%0A+%5BTURKISH+I%5D%3A+https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FTurkish_dotted_and_dotless_I%0A -- Michel Fortin michel.for...@michelf.ca http://michelf.ca ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
* Carl Jacobsen li...@carlrj.com [2014-07-10 12:50]: So, you might have: content-type=text/markdown flavor=tables+titleblock processor=floobity-1.2.3 That’s very nice, except it will never happen. • No user is going to annotate their files in such a way that this MIME type would ever show up in the wild in such specificity, unless they use special software which automatically records the relevant metadata (rather than just a text editor + file system workflow). • No implementor is going to write a Markdown processor that is actually capable of dealing with this MIME type. (Except of course the author of floobity 1.2.3 itself, in this example, of course – which is not for any attempt at making it work in a generic way.) • If the flavours refer to existing syntax extensions and modifications, those are all only vaguely specified, and the implementations that offer them are not likely to be changed to follow a more rigorous spec of the respective syntax extension any time soon. So in practice these flavour specs are no more well-defined than saying the document is (some kind of) Markdown. • Documents are generally written for a specific processor, not for some particular combination of syntax extensions in the abstract. There are a number of processors which implement half a dozen separate syntax extensions. Documents written for these processors notionally employ all of these syntax extensions. Will documents in e.g. GitHub-Flavored Markdown always have to list the entire enchilada in their MIME type (instead of just saying “GFM”)? Or do you force whatever part of the infrastructure picks the MIME type to parse the document (and contain knowledge of all possible syntax extensions) to figure out which of them are actually used? • I won’t make a separate bullet point for the endless effort of keeping track of all the possible syntax extensions, which is going to be a cat herder job, because that should be an obvious problem. But what if someone wants to implement a new syntax extension – what process do they have to go through before they can assign a truthful MIME type to their documents? Metadata is hard. Let’s go shopping. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
On Jul 09, 2014, at 11:49 AM, Sean Leonard dev+i...@seantek.com wrote: Hi markdown-discuss Folks: I am working on a Markdown effort in the Internet Engineering Task Force, to standardize on text/markdown as the Internet media type for all variations of Markdown content. You can read my draft here: http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00 . My response below is lengthy but covers a number of different points including some raised later in the discussion by others. Sean, have you reached out to Mr. Gruber specifically? I mention this because in the past I have CCed him directly on a response I sent to this list which prompted him to respond (admittedly that happened some years ago). I suspect he might be amenable to the general idea though. A search of the list archives turned up a previous discussion [1] where he indicated a willingness to put in some work to obtain a mime type for markdown. Of course, that was back when he was still actively involved. Your mileage may vary. [1]: http://article.gmane.org/gmane.text.markdown.general/1179 In any event, I have some thoughts about your proposal. I like it for the most part. But a few comments on some specifics: Why do we need a Mime Type? First of all, when is this necessary? In order words, when is plain markdown being sent around such that it needs a mime type? In my experience, REST API's (for example) use JSON or XML which may contain some Markdown text among other data. That other data may identify that the text is markdown, but the mime type for the file is JSON or XML (or at least the appropriate mime type for that file type). Or are you proposing that everyone standardize on a way to identify the markdown text within JSON and XML documents as Markdown text? What am I missing here? Encodings -- To shed a different light on the encoding issue, consider Python-Markdown (disclosure: I'm the primary developer). Just as in Python 3 (where all strings are Unicode), Python-Markdown only works with Unicode. You pass Unicode text in, and you get Unicode text out. It is up to the user of the library to concern themselves with encoding and decoding a file to/from a specific encoding. As Python provides the libraries to do that, it is not a big problem -- although for those used to working with byte strings it may be a little jarring (I'm seeing that reaction from people who are experimenting with Apple's new Swift Language -- which also supports Unicode only strings). The point is, the Python-Markdown implementation has no use for the encoding (except for the included wrapping commandline script). Of course, the user (user of the library) will care about that and will need some way to identify the encoding before converting and passing the input on to the Python-Markdown library. So yes, encoding is very much a real, needed piece of meta-data. However, if the markdown text is included in a JSON file (see my previous point above), then wouldn't the encoding be defined for the JSON file, not the markdown text specifically. The JSON parsing library would just spit out a Unicode string -- in which case, why do we need this? Flavors - To me, flavors seems like a disaster waiting to happen. Sean, I realize you have specifically stated a lack of understanding here, so lets go back in time. The following may not be an all-inclusive (or in proper order of events) history of Markdown, but provides enough (I hope) to make a point. Way back when, the flavor of markdown you used depended almost entirely on which language (Perl, PHP, Python...) you were using to code your project (blog, wiki, CMS, etc.). If you where using PHP, them your flavor was PHP Markdown... There was only one implementation per language and they (mostly?) agreed with each other. In that day flavor was completely pointless. I suspect a number of us resistant to the flavors part of your proposal are from that period in Markdown's history. Of course, then Ruby came along. I don't remember which library was which, but when the first library came out, it was not very good (lots of bugs and slow). Then a second library came out which also wasn't very good, but in different ways (except for the slow part). Some people wrote their markdown documents with the bugs of the first implementation in mind, while other's wrote their documents with the second in mind. Then a few projects started offering users the option to pick which Ruby implementation of Markdown to use for each individual document - and flavors were born. Then other people started making ports of those projects to other languages and the flavors followed -- even though the other languages didn't really have any choices. As a reminder, Github came out of that Ruby culture, which might explain why Github-Flavored-Markdown ever existed in the first place (interesting side note: Gruber appears
Re: text/markdown effort in IETF (invite)
This isn't entirely true. For example, try to insert a list immediately preceding an indented (not fenced) code block, where the code block is *not* part of the list. By doing so, you convert the code block into a paragraph that becomes part of the last list item. Indenting with one more tab results in a code block, but that code block is still part of the list. This seems to be one of the first gotchas that gets many new users to Markdown. I suppose it's debatable as to how non-local that effect is considered, since the code block immediately follows the list. But inserting one structure (the list) breaks something that previously worked (the code block). A less debatable example is fenced code blocks (not part of Markdown per se, but part of many derivatives.) I was reluctant to include fenced code blocks in MultiMarkdown for just this reason. To my chagrin, after adding fenced code block support to MMD, I then realized just how much of a bad idea they are. They are the one syntax element you can't identify by simply looking local to that portion of the text. You have to start all the way at the beginning, which can be a headache if you have a novel contained in a single text file. Consider the following excerpt from a document: ``` This is *text* ``` This is more *text* ``` Without knowing the entire document before the snippet, one cannot determine which of those sentences is a code block, and which is a paragraph. The first row of single quotes could be starting a new code block, or it could be closing a previous code block. One accidental fence delimiter at the beginning of a document could alter the meaning of the entire thing. It's basically an even/odd problem, and the only way to know if a particular fence is even or odd is to count all the preceding fences. This may not really matter that much when a single person creates a single document to be converted once into a single web page. But in more complicated real world use, this can be problematic. I don't know that there is much to do about it at the moment, and I don't currently plan to yank fenced code blocks from MMD. But I mention it so that it can be considered when proposing additional new features on top of the Markdown base set. FTP On 7/10/14, 9:30 AM, Aristotle Pagaltzis wrote: I’m afraid you entirely misunderstood what I meant by non-local. What I was referring to is, e.g. in HTML you can insert tags at the top of a document such as `table` or `pre` which then change the way the entire remaining document is to be rendered. They affect the document non-locally. Markdown does not have such constructs. If you include a Markdown Extra table in the document and you put that document through Markdown.pl, you will get a garbled form of the source of the table syntax as output for the table, but the misrendering is only local. The rest of the document will be unaffected and will render correctly. -- Fletcher T. Penney fletc...@fletcherpenney.net ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
* Fletcher T. Penney fletc...@fletcherpenney.net [2014-07-10 18:30]: I suppose it's debatable as to how non-local that effect is considered, I do consider that local. “Local-enough” at least. Tellingly though it’s also the most common single reason for “how do I” user inquiries on this list. A less debatable example is fenced code blocks Yes, true. The annoying thing is, while I was against them when the proposal was brought up for Markdown in general, after spending some time using them (by way of GitHub), I do find them convenient as a user. So now I have a dilemma. — • — Still though – because fenced code blocks are an extension, they don’t much change the principle of what I said: if you use a fenced code block, then try to render the document using some other processor which doesn’t support them, you get a garbled code block and then the rest of the document after that looks fine. Conversely a documents written for processors that do not support fenced code blocks are rather unlikely to contain something that looks as if it were – which would then lead to large-scale botch if you tried to render them using a processor that supports fenced code blocks. (I feel this is especially so for backtick fences. Tilda fences seem to have some remote likelihood of being used as an innocuous part of a non-fenced-code-block document.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
On Jul 10, 2014, at 8:49 AM, Waylan Limberg waylan.limb...@icloud.com wrote: In my experience, REST API's (for example) use JSON or XML which may contain some Markdown text among other data. That other data may identify that the text is markdown, but the mime type for the file is JSON or XML (or at least the appropriate mime type for that file type). I’m no [REST Police][1], but in my understanding, REST encourages the embracing of HTTP verbs to perform actions on hypertext objects. Consider an API call that updates the Markdown source of a blog post, for example. You are entirely correct that there is a strong chance that this API call would actually send an updated copy of a JSON object including fields such as “title”, “date”, “url”, and “body”, the last of which may implicitly or explicitly be Markdown data. (And the MIME type on that call would be application/json or whatever.) But perhaps the most RESTful way to do this would be to send a plain Markdown file (as text/markdown). (As far as the metadata goes, the server could extract the title from the markdown document itself (first level-one heading or first line of text, for example), set the date automatically, and so on. That’s not to say that a JSON API for updating a blog post isn’t RESTful, but rather that the non-JSON, pure-Markdown API is where the new MIME type would be most needed. [1]: https://twitter.com/RESTPOLICE Alan ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
case in reference links (was: Re: text/markdown effort in IETF)
+++ Michel Fortin [Jul 10 14 07:53 ]: Le 10-juil.-2014 à 1:04, John MacFarlane j...@berkeley.edu a écrit : +++ Michel Fortin [Jul 09 14 18:07 ]: Fun fact: PHP Markdown is mostly encoding agnostic. It understands UTF-8 sequences but any byte that is not a valid UTF-8 sequence is treated as a character in itself. It's only relevant when converting tabs into spaces however, and only if you have non-ASCII characters before the tab. Small amendment: There are at least two places where the difference between utf-8 and latin1 matters: tab expansion (as you note) and reference links, since these are stipulated to be case insensitive. (Case conversion is sensitive to the encoding.) Like Markdown.pl, PHP Markdown will just treat non-ASCII characters in a case-sensitive way so in my case it doesn't matter. I think this is a deficiency in Markdown.pl. The syntax description says that reference links are case-insensitive, and it doesn't say anything about this just applying to ascii references. I think someone who writes in, say, Spanish, would be quite naturally expect words with accents to behave the same as words without accents in reference links. By the way, I'm not sure what the motivation for making the reference links case-insensitive was. I conjecture that it was to allow the following sort of thing: [Foo][] is better than [bar][]. And [Bar][] is worse than [foo][]. [foo]: /url1 [bar]: /url2 This is a good motivation: it would be a burden to have to define separate references for capitalized and uncapitalized versions of a phrase, or to use the longer form `[Foo][foo]` for capitalized versions. But this motivation extends naturally beyond ascii. Hence, I think markdown processors *should* do a proper unicode case fold in determining when references match. Unfortunately, as you point out, this becomes very complex, and brings in locale dependence for a few cases (e.g. Turkish). Still, I think it's the ideal we should aspire to. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
+++ Aristotle Pagaltzis [Jul 10 14 14:18 ]:
• No implementor is going to write a Markdown processor that is actually
capable of dealing with this MIME type. (Except of course the author
of floobity 1.2.3 itself, in this example, of course – which is not
for any attempt at making it work in a generic way.)
Pandoc can already do this. Quick demo:
pandoc -s -f markdown_strict+pandoc_title_block+tex_math_dollars -t
markdown_strict+mmd_title_block+tex_math_double_backslash
% Demo
% John
% July 1, 2014
Here is some math: $e=mc^2$.
^D
author: John
date: July 1, 2014
title: Demo
Here is some math: \\(e=mc^2\\).
Here's my current list of extensions/variations (from the pandoc
source code). Of course, it's nowhere near exhaustive:
Ext_footnotes -- ^ Pandoc/PHP/MMD style footnotes
| Ext_inline_notes-- ^ Pandoc-style inline notes
| Ext_pandoc_title_block -- ^ Pandoc title block
| Ext_yaml_metadata_block -- ^ YAML metadata block
| Ext_mmd_title_block -- ^ Multimarkdown metadata block
| Ext_table_captions -- ^ Pandoc-style table captions
| Ext_implicit_figures-- ^ A paragraph with just an image is a figure
| Ext_simple_tables -- ^ Pandoc-style simple tables
| Ext_multiline_tables-- ^ Pandoc-style multiline tables
| Ext_grid_tables -- ^ Grid tables (pandoc, reST)
| Ext_pipe_tables -- ^ Pipe tables (as in PHP markdown extra)
| Ext_citations -- ^ Pandoc/citeproc citations
| Ext_raw_tex -- ^ Allow raw TeX (other than math)
| Ext_raw_html-- ^ Allow raw HTML
| Ext_tex_math_dollars-- ^ TeX math between $..$ or $$..$$
| Ext_tex_math_single_backslash -- ^ TeX math btw \(..\) \[..\]
| Ext_tex_math_double_backslash -- ^ TeX math btw \\(..\\) \\[..\\]
| Ext_latex_macros-- ^ Parse LaTeX macro definitions (for math only)
| Ext_fenced_code_blocks -- ^ Parse fenced code blocks
| Ext_fenced_code_attributes -- ^ Allow attributes on fenced code blocks
| Ext_backtick_code_blocks-- ^ Github style ``` code blocks
| Ext_inline_code_attributes -- ^ Allow attributes on inline code
| Ext_markdown_in_html_blocks -- ^ Interpret as markdown inside HTML blocks
| Ext_markdown_attribute -- ^ Interpret text inside HTML as markdown
-- iff container has attribute 'markdown'
| Ext_escaped_line_breaks -- ^ Treat a backslash at EOL as linebreak
| Ext_link_attributes -- ^ MMD style reference link attributes
| Ext_autolink_bare_uris -- ^ Make all absolute URIs into links
| Ext_fancy_lists -- ^ Enable fancy list numbers and delimiters
| Ext_lists_without_preceding_blankline -- ^ Allow lists without preceding
blank
| Ext_startnum-- ^ Make start number of ordered list significant
| Ext_definition_lists-- ^ Definition lists as in pandoc, mmd, php
| Ext_example_lists -- ^ Markdown-style numbered examples
| Ext_all_symbols_escapable -- ^ Make all non-alphanumerics escapable
| Ext_intraword_underscores -- ^ Treat underscore inside word as literal
| Ext_blank_before_blockquote -- ^ Require blank line before a blockquote
| Ext_blank_before_header -- ^ Require blank line before a header
| Ext_strikeout -- ^ Strikeout using ~~this~~ syntax
| Ext_superscript -- ^ Superscript using ^this^ syntax
| Ext_subscript -- ^ Subscript using ~this~ syntax
| Ext_hard_line_breaks-- ^ All newlines become hard line breaks
| Ext_ignore_line_breaks -- ^ Newlines in paragraphs are ignored
| Ext_literate_haskell-- ^ Enable literate Haskell conventions
| Ext_abbreviations -- ^ PHP markdown extra abbreviation definitions
| Ext_auto_identifiers-- ^ Automatic identifiers for headers
| Ext_ascii_identifiers -- ^ ascii-only identifiers for headers
| Ext_header_attributes -- ^ Explicit header attributes {#id .class k=v}
| Ext_mmd_header_identifiers -- ^ Multimarkdown style header identifiers
[myid]
| Ext_implicit_header_references -- ^ Implicit reference links for headers
| Ext_line_blocks -- ^ RST style line blocks
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
On Fri, Jul 11, 2014 at 3:58 AM, John MacFarlane j...@berkeley.edu : Here is some math: \\(e=mc^2\\). Here's my current list of extensions/variations (from the pandoc source code). Of course, it's nowhere near exhaustive: Ext_footnotes -- ^ Pandoc/PHP/MMD style footnotes | Ext_inline_notes-- ^ Pandoc-style inline notes | Ext_pandoc_title_block -- ^ Pandoc title block | Ext_yaml_metadata_block -- ^ YAML metadata block As much as admirable pandoc is, testing that is difficult. Given that features can nested, the combinations is easily greater than the number of lines in https://github.com/jgm/pandoc/blob/master/tests/Tests/Readers/Markdown.hs Markdown is an over-loaded term. It is safe to say that, there are at-least two useful Markdowns 1) Plain Useful for, * Non-technical publishing * Simple comment systems ( Markdown.pl ) 2) Complete * DocBook / Latex style publishing * Editors ( MultiMarkdown ) A third type of Markdown can be labelled Proprietary Markdown, of which Github Markdown is a prime example. Markdown implementations can give pre-processors and post-processors, which can implement Proprietary Extensions. I don't understand why different things have to be conflated together. If the IETF draft is from the perspective of publishing 1) can be ignored. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
