I think he means the content of the codeblock should be CSV only and let the attributes to encode all the necessary metadata.

I also agree that YAML metadata is more natural for data (so the value wouldn't always be a string and requires additional parsing, and can have markdown, which is important for caption). I don't entirely understand the workflow he describe, probably he means another filter that process the attribute and inject a CSV there. (That's the primary reason on the feature request in panflute that allow truly empty YAML. And thanks for considering that.)

I'm thinking a more natural way to specify the code block is a CSV is not by class but by a special key-value pair, say, `filter=csv2table`. This way seems to fit better in the picture that "panflute auto-install the filter for the user". The "filter" YAML key in the main document specify which filter pan flute will execute, and the attribute in any element `filter=...` determines where would the filter be acting upon. (at least for those elements that support attributes).

For my filter, I am thinking may be I should turn it into a cli that's like pandoc but for tables. Unimaginatively, let's call that panxls for the meanwhile. Suppose it can do `panxls -f csv -t json`, and also HTML, LaTeX, xlsx, etc. Then provide a thin wrapper that's a pandoc filter and define a general syntax to apply the cli in a pandoc markdown document.

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/38bfec67-90f0-4d71-b054-1eedfd853d96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.