<br><br><div class="gmail_quote">On Tue, Sep 20, 2011 at 1:30 AM, David Sanson <span dir="ltr">&lt;<a href="mailto:dsanson@gmail.com">dsanson@gmail.com</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>
On Sep 19, 2011, at 4:02 PM, Rob McBroom &lt;<a href="mailto:mailinglist0@skurfer.com">mailinglist0@skurfer.com</a>&gt; wrote:<br>
<br>
&gt; Those sound like reasons for the metadata to *identify* the abstract, but I see no requirement that it must be literally *stored* there. If the metadata contained something like<br>
&gt;<br>
&gt;    abstract: relative/path/to/abstract.mdown<br>
&gt;<br>
&gt; That would allow for all of the above scenarios while keeping the metadata syntax/section simple.<br>
<br>
</div>But that makes the document far less portable, and I&#39;m liable to lose the extra file at some point. I&#39;d much rather have it be self-contained---not, of course, if that means that the document suddenly becomes weirdly ugly and complicated, but I don&#39;t see anyone proposing a solution that makes documents weird and ugly and complicated.<br>

<font color="#888888"><br></font></blockquote><div><br></div><div>Given that the abstract is actually part of the content (it is generally printed as part of the document, right?) it would seem more sensible to have the meta-data refer to a section name/path within the document. We can probably assume any markdown parser is capable of identifying the content between a heading and its next same-or-higher-depth sibling. &quot;Abstract&quot; could be a default value, supporting the &quot;simplest case first&quot; example Fletcher T. Penney provided above; </div>
<div><br></div><div>This way content is in the right place (in the document, and appearing where you would expect it to with a simple abstract-unaware markdown converter), english speakers just write their document, and others can provide the &quot;abstract&quot; header, without needing to know anything about parsing or serialization rules.</div>
<div><br></div><div>I realize I&#39;m following up on the least-important aspect of this conversation, but I do wonder: what are genuine use cases where meta-data really does contain structured/formattable content that should not be considered part of the document content? It doesn&#39;t look like the abstract is really a valid case.</div>
<div><br></div><div><br></div><div><br></div><div> </div></div>