Opinions on in-band variation signaling

[Sean Leonard]

On Nov 11, 2014, at 2:49 PM, Michel Fortin <michel.fortin at michelf.ca> wrote:

> 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.

Ok, thanks. That’s the “main thing” I wanted to know.

> 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. 

Yes, Michel is right; sorry if there was any confusion on this part.

> Also, lines prefixed by a `%` are ugly, I would never suggest such a thing.

That was not suggested by you; it is, however, pandoc title block syntax. See <http://johnmacfarlane.net/pandoc/README.html#extension-pandoc_title_block>.

This raises an important issue: pandoc will only recognize its title block syntax if it is at the start of the file. If you put any text above it, the % block loses its pandoc meaning. Therefore, unless you treat the directives as metadata in a container/enclosure format, you’re not going to get the behavior that you want.

Which goes to the broader point that *any* metadata recorded in-band, even data that is “comment-y” such as my proposed link reference armor:

[!pandoc]: # “Ignore”
blah

is bound to cause problems with some Markdown implementation out there. There is no free lunch.

Sean

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4825 bytes
Desc: not available
URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20141111/0a07d28b/attachment.bin>