Markdown would be very nice

[fosdev]

https://github.com/alps-io/spec/blob/master/draft-00.txt#L593-L597

[mamund]

yeah, i guess we should decide between md or asciidoc as a start, not both. md is more common, right?

[fosdev]

Lot of people using md these days. Never see anything in asciidoc that I read or write.

[mamund]

LOL, I use AD every day ;) no worries, md is cool w/ me.

On Wed, Feb 12, 2014 at 2:58 PM, Mark W. Foster notifications@github.comwrote:

Lot of people using md these days. Never see anything in asciidoc that I read or write.

Reply to this email directly or view it on GitHubhttps://github.com/alps-io/spec/issues/24#issuecomment-34910315 .

[Xophmeister]

Another vote for markdown from me. Although, of course, there's the perennial issue of what exactly that means, given its loose spec and multiple/vendor-specific definitions. My view is that should be left unto the client to worry about!

Is there any reason why both AsciiDoc and Markdown can't be supported by the ALPS spec? Why the "one or the other" attitude, besides brevity's sake?

[mamund]

i added asciidoc because it offers the same benefits of markdown w/o the difficulty of sorting out vendor politics ;)

if we do add support for MD, i'd want to use this I-D as a guide (including the indication of "variants" to help sort our implementations) https://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-05

comments?

mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund

On Thu, Jan 15, 2015 at 6:09 AM, Christopher Harrison < notifications@github.com> wrote:

Another vote for markdown from me. Although, of course, there's the perennial issue of what exactly that means, given its loose spec and multiple/vendor-specific definitions. My view is that should be left unto the client to worry about!

Is there any reason why both AsciiDoc and Markdown can't be supported by the ALPS spec? Why the "one or the other" attitude, besides brevity's sake?

— Reply to this email directly or view it on GitHub https://github.com/alps-io/spec/issues/24#issuecomment-70070866.

[Xophmeister]

Given the holy war and schism that was sparked the last time a standardisation attempt was made, this I-D seems like a sensible and pragmatic approach. So, yes: Sounds like a plan!

[mamund]

cool. do you want to whip up a PR that adds MAY support for markdown based on this I-D? ​

[fosrias]

So, there is some controversy in play ATM on markdown per the following:

• https://twitter.com/markdown/status/507341395137658880
• http://blog.codinghorror.com/standard-markdown-is-now-common-markdown/

Apparently John Gruber, author of Markdown has a problem with the aforementioned spec and use of Markdown. CommonMark, I believe, is what is making its way toward a spec. So, not sure how all this affects the proposed RFC.

[Xophmeister]

The I-D mentioned by @mamund side-steps this issue by not imposing any spec (there's nary a Backus-Naur to be seen), but rather deferring to the client to parse, using a variant parameter on the media type as a "hint". In my opinion, it's actually quite careful not to rile Gruber -- his work is explicitly referenced as being standard -- and recommends an IANA registry for variants (e.g., CommonMark, GitHub Flavoured, etc.)

[fosrias]

Ok. Did not read the spec close enough. :thumbsup: from me @mamund.

On Jan 16, 2015, at 6:03 PM, Christopher Harrison notifications@github.com wrote:

The I-D mentioned by @mamund https://github.com/mamund side-steps this issue by not imposing any spec (there's nary a Backus-Naur to be seen), but rather deferring to the client to parse, using a variant parameter on the media type as a "hint". In my opinion, it's actually quite careful not to rile Gruber -- his work is explicitly referenced as being standard -- and recommends an IANA registry for variants (e.g., CommonMark, GitHub Flavoured, etc.)

— Reply to this email directly or view it on GitHub https://github.com/alps-io/spec/issues/24#issuecomment-70285481.