<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 06/23/2011 05:29 PM, <a class="moz-txt-link-abbreviated" href="mailto:Bowerbird@aol.com">Bowerbird@aol.com</a> wrote:
    <blockquote cite="mid:86713.6fad5b8e.3b350a42@aol.com" type="cite"><font
        face="arial,helvetica"><font color="#000000" face="Lucida
          Grande" lang="0" size="4">alan said:<br>
          &gt;&nbsp;&nbsp; I think I am in agreement, <br>
          &gt;&nbsp;&nbsp; if by "isn't necessary" you mean to say that<br>
          &gt;&nbsp;&nbsp; simply providing more features to Markdown <br>
          &gt;&nbsp;&nbsp; doesn't force end users to use them, <br>
          &gt;&nbsp;&nbsp; or even really know they exist.<br>
          <br>
          except that wasn't what i meant.<br>
          <br>
          i mean that it's not necessary to trade simplicity<br>
          in order to get the power of additional features...<br>
          <br>
          indeed, i believe that -- in the purview of a system<br>
          whose chief asset is its simplicity -- that would be<br>
          a bad trade.&nbsp; and, as i've read gruber, so would he;<br>
          he is an admirer of the grace apple brings to bear.<br>
          <br>
          <br>
          &gt;&nbsp;&nbsp; I know I am firmly on the side of "this stuff -- <br>
          &gt;&nbsp;&nbsp; footnotes, DLLs, fenced code, attributes on headers, <br>
          &gt;&nbsp;&nbsp; automatic TOC -- is useful, and sensibly implemented <br>
          &gt;&nbsp;&nbsp; in the Markdown plain-text spirit, and thus good,"
          myself.<br>
          <br>
          i am all in favor of all of those more-powerful features.<br>
          <br>
          i just don't believe it's necessary to give up _simplicity_<br>
          in order to get them.&nbsp; you might have to sacrifice some<br>
          _customizability_, but that's an acceptable trade, for me.<br>
          <br>
          at one point, i was ready to discuss a range of stuff that<br>
          could reduce the complexity of markdown variants, but<br>
          nobody else seemed interested in having that discussion.<br>
          so the moment passed.&nbsp; and i'm not inclined to do it now.<br>
          <br>
          but, just as one for-instance, "markdown extra" lets you<br>
          assign an i.d. attribute to a header, by adding it like this:<br>
          &gt;&nbsp;&nbsp; ## Header 2 ##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {#header2}<br>
          <br>
          the extra power that this gives users is undeniable, and<br>
          much-needed.&nbsp; but that convention is just an ugly hack.<br>
          it's extra work, and it's error-prone, plus it looks awful.<br>
          why wouldn't/shouldn't an i.d. be assigned automatically?<br>
          <br>
          so other variants, such as "multimarkdown", do just that.<br>
          but, even in its own user-manual, it gets itself confused,<br>
          with multiple headers being auto-assigned the same i.d.:<br>
          <br>
          &gt;&nbsp;&nbsp; id="advanced"<br>
          &gt;&nbsp;&nbsp; id="basic"<br>
          &gt;&nbsp;&nbsp; id="bibtex"<br>
          &gt;&nbsp;&nbsp; id="compiling"<br>
          &gt;&nbsp;&nbsp; id="footnotes"<br>
          &gt;&nbsp;&nbsp; id="images"<br>
          &gt;&nbsp;&nbsp; id="rawhtml"<br>
          <br>
          pandoc checks for such duplicates, and appends a suffix<br>
          (-1, -2, etc.) to assure that each one has a unique value...<br>
          that's an ok solution, except that it makes it difficult to<br>
          know what the i.d. is for any specific header because you<br>
          have no idea whether it required an appendage, or not...<br>
          <br>
          i myself, with z.m.l., simply require that each header be<br>
          unique to begin with, thus avoiding that potential glitch.<br>
          and i assign an i.d. to each paragraph, because... why not?<br>
          <br>
          that's how you give the user more power _without_ adding<br>
          more complexity.&nbsp; (or gumming up the file with any crap.)<br>
          <br>
          -bowerbird</font></font><br>
    </blockquote>
    <font face="arial,helvetica"><br>
      Fascinating --- I read this list and I see feature requests and
      discussions going nowhere because nobody gets beyond the fact the
      bdfl of markdown has gone awol. Thus the base markdown is Gruber's
      perl markdown implementation. Anything that others add are "above
      and beyond" the base (even if they fix edge cases). Thus markdown-<u>extra</u>
      for tables and such.<br>
      <br>
      Yet here we are discussing a zen-to-markdown converter and want to
      know which "above and beyond" version it should adhere to. Sorry
      but, in light of the very real inability of anyone else to take
      over as bdfl and point the way, if you want to convert to markdown
      you currently need to use the base perl markdown as the reference.
      Otherwise you're converting to a superset of markdown.<br>
      <br>
      You could create a converter zml-to-pandoc, or
      zml-to-multimarkdown, but they won't be zml-to-markdown. And
      really, the choice depends on your target audience and what they
      are going to do with it.<br>
    </font>
  </body>
</html>