Regarding the text/markdown registration: At least one commentator (Larry Masinter) specifically requested that the variant identifier be included in-band in the Markdown content, rather than as part of the metadata. I disagree with in-band signaling (as has been registered earlier on this list). Nevertheless, I wanted to take a straw poll and see if anyone has tried to implement in-band Markdown variation identifiers, with any success. Do any implementers have experience with picking the type of Markdown based on some info at the top of the Markdown content? Does it work?or will it never work? Or is it ?bad? for particular reasons? By in-band, I mean a Markdown file with content like this:>>>!pandoc % This is a Title % Sean Leonard % November 2014 Blah blah *blah*. <<< (fortin?s suggestion)>>>[!pandoc]: # "This is a pandoc document." % This is a Title % Sean Leonard % November 2014 Blah blah *blah*. <<< (seantek?s suggestion) -Sean
Was thinking that generic block directives concept in http://talk.commonmark.org/t/block-directives could assist with this.>>>!pandoc: This is a Title Sean Leonard November 2014 <<< (compact) or if there is spaces in the metadata block. No need for %, since we know that it is metadata already.>>>!pandoc: :::::::::::::::::::::::::::::::: This is a Title Sean Leonard November 2014 :::::::::::::::::::::::::::::::: <<< (fenced) Good for document declaration. E.g. should we load resume.css or blog.css default styles. On Wed, Nov 12, 2014 at 10:47 AM, Sean Leonard <dev+ietf at seantek.com> wrote:> Regarding the text/markdown registration: > > At least one commentator (Larry Masinter) specifically requested that the variant identifier be included in-band in the Markdown content, rather than as part of the metadata. I disagree with in-band signaling (as has been registered earlier on this list). Nevertheless, I wanted to take a straw poll and see if anyone has tried to implement in-band Markdown variation identifiers, with any success. Do any implementers have experience with picking the type of Markdown based on some info at the top of the Markdown content? Does it work?or will it never work? Or is it ?bad? for particular reasons? > > By in-band, I mean a Markdown file with content like this: > >>>> > !pandoc > % This is a Title > % Sean Leonard > % November 2014 > > Blah blah *blah*. > <<< (fortin?s suggestion) > >>>> > [!pandoc]: # "This is a pandoc document." > % This is a Title > % Sean Leonard > % November 2014 > > Blah blah *blah*. > <<< (seantek?s suggestion) > > -Sean > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss at six.pairlist.net > https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
Before this discussion derails on a syntax bikeshedding, I think I should highlight the important part: Sean Leonard wrote:> Do any implementers have experience with picking the type of Markdown based on some info at the top of the Markdown content?To my knowledge, no one is doing that. But it'd be interesting to hear about it if someone is doing it. As for this:> By in-band, I mean a Markdown file with content like this: > >>>> > !pandoc > % This is a Title > % Sean Leonard > % November 2014 > > Blah blah *blah*. > <<< (fortin?s suggestion)I suggested privately to you that using `!pandoc` would be better as a header than `Content-Type: text/markdown; variant="pandoc"` if you wished people to actually write something in a file. But for me this is an enclosure format for Markdown (similar to how mp4 is an enclosure format for many codecs.). The actual Markdown content starts after the metadata header. Also, lines prefixed by a `%` are ugly, I would never suggest such a thing. -- Michel Fortin michel.fortin at michelf.ca https://michelf.ca -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4154 bytes Desc: not available URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20141111/7c2ae133/attachment-0001.bin>
* Sean Leonard <dev+ietf at seantek.com> [2014-11-12 00:50]:> At least one commentator (Larry Masinter) specifically requested that > the variant identifier be included in-band in the Markdown content, > rather than as part of the metadata. I disagree with in-band signaling > (as has been registered earlier on this list).Both have value. Ruby?s postulate: The accuracy of metadata is inversely proportional to the square of the distance between the data and the metadata. That is to say, a value signalled in-band will be correct much more often than one signalled via MIME/HTTP headers. Also, in-band vs out-of-band simply address different scenarios. An in-band signal travels with the data automatically, without any special measures taken, whereas out-of-band metadata has a fair chance of getting lost somewhere in transit. How is a user agent supposed to store the variant parameter from the content-type after downloading a Markdown file to disk? But if you want to make decisions about the data during transit, having to parse the payload to find the signal is prohibitively expensive. An out-of-band signal is cheap, and is visible to a lot of infrastructure that would never implement such specialised parsing of payloads such as Markdown. (I mean, that is the exact same reason for having a MIME type separate from text/plain in the first place.) It?s nonsensical to portray this as a binary choice between two options. Those are two separate choices and discussions. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>