<br><br><div class="gmail_quote">On Tue, Sep 20, 2011 at 9:56 AM, John MacFarlane <span dir="ltr">&lt;<a href="mailto:jgm@berkeley.edu">jgm@berkeley.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
</div>I think that the abstract is a fine case. Although one *could* handle<br>
it the way you suggest, by having the metadata specify a section<br>
of the document to use as the abstract, I don&#39;t see the advantage of<br>
that. It is natural distinguish between the body text, which is *always* part<br>
of the produced document, whether a fragment or a standalone document is being<br>
produced, and regardless of the format or template used, and the metadata,<br>
which sometimes appear in the produced document, depending on one&#39;s purposes,<br>
and which appear differently in different formats. Once you make this<br>
distinction, the abstract clearly falls on the side of the metadata.<br>
<br>
</blockquote><div><br></div><div>In that case, you&#39;re talking about metadata in the more general sense - like link definitions, footnotes, and other constructs that are currently treated as a special case in markdown. I&#39;m all for having a special syntax for defining the abstract, as long as the author doesn&#39;t have to worry about any escaping conventions and can just write it like he/she would any other regular markdown content.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Other cases:<br>
<br>
* bibliographic data for the document itself, which you might want<br>
  to print in some presentations but not others<br>
* revision history<br>
* tags<br>
* bibliography entries used in the document<br>
* settings for things like default stylesheets<br>
<br></blockquote><div><br></div><div>Point taken, most of these are good cases for supporting structured content, but not formattable/markdown content, right?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Currently you need to specify the bibliography database on the<br>
command line as well (it can be bibtex, endnote, or any number<br>
of other formats).  Ideally, though, the document itself should<br>
specify where its bibliographical entries are coming from.<br>
This could just be a file path, but if you want the document to<br>
be truly portable, it would be nice to be able to include the structured<br>
bibliography entries themselves in metadata at the end of the document.<br>
This could be done easily with a data description language as<br>
powerful as lua/yaml/json.<br></blockquote><div><br></div><div>Absolutely - but the (possibly unattainable) ideal would be a situation where tools and experts can specify complex structured metadata, and regular joe can change his title, author, and other basic/simple values and lists, specifying values that contain apostrophes, commas and other natural punctuation, wihout blowing anything up in the process. As soon as he needs to specify/modify something that contains structure (or even something multi-line?) it seems fair that he should have to use a tool or do some research on the standard (esp. as most if not all of the structured-data use cases relate to tools already).</div>
<div><br></div><div>My concern with a pure-lua/yaml/json metadata format is that it requires specialized knowledge (not related to the existing markdown standards/experience) on the part of the user for even the most trivial changes to the simplest fields - *especially* if structured/markdown content such as the abstract is placed in a metadata field!</div>
<div><br></div><div><br></div></div>