keith said:
just submit pandoc, and will we will see what Lee has to say.
oh, so now you want to try and send _me_ on that wild-goose chase! no way, mister. :+) but really, keith, what did you mean by that puzzling "no human intervention" comment? do you have some gerbils who'll run the test? :+) *** that $100 "challenge" can't be taken seriously. for anyone who wants to know why, seriously, i am all too happy to explain the subterfuge... lee _thought_ that he could demonstrate that light-markup languages are not fully specified. thus, by requiring different ones to produce what is essentially the same underlying code, he thought he could expose the holes in each. what he didn't know is that the schemes _are_ fully specified, and thus can indeed create code which accomplishes even a fairly complex book, in a fairly standard manner, such that that code would indeed qualify as "essentially" equivalent. in fact, the degree of full-specification obtained is complete enough that these markup systems can even be translated in a one-to-one fashion. and not only can they "be translated" that way, the conversion can be done _programmatically_, and pandoc is the existence-proof for _that_... so lee was significantly underinformed, and his "challenge" merely exposed that chilling factoid. but lee is a clever and devious person, who knows how to cover his ass, so he found a way to do that, in the off-chance that he unknowingly was wrong. his challenge specified that _he_ would prepare the various light-markup files, meaning he could _sabotage_ the full-specification of the schemes. lee made it _appear_ as if he was betting that you couldn't make a basket shooting from mid-court. (or what he believed would be a mid-court shot, even though, with pandoc, it was a mere lay-up.) but, with a little shift at the end, he changed it, such that he was betting that _he_ would miss a shot from mid-court. would you take _that_ bet? would you take a bet that he could miss a lay-up? ok, fine, lee wanted to make sure that he wouldn't have to give away his $100. who could blame him? but to think this proves anything is just ridiculous. nonetheless, a simple contradictory point remains. namely, none of the benefits of any light-markup system _ever_required_ that such a system could be converted flawlessly into _other_ light-markup. the object of light-markup is to convert to .x/html, .epub, .mobi, .pdf, or some other _output_format_, and _not_ to convert to some other _input_format._ i mean, it's _nice_ that pandoc can convert between markdown and restructured-text and asciidoc, and many other formats, but it's certainly not necessary. markdown does what it's _meant_ to do, regardless. and so does restructured-text. and so does asciidoc. lee is trying to shift your attention to a trivial thing. he wants you to focus on a meaningless "conversion" between light-markup formats, instead of the _more_ important matter that light-markup converts to .html. because lee wants you to do your authoring in .html, not light-markup. but light-markup is much simpler, so i'm not really sure why he wants to waste your time. and let's be absolutely clear about something vital... this choice of a "master format" does _not_ entail any need to give anything up. you don't have to "choose" between using light-markup and .html. because light-markup can be converted to .html... with the simple click of a button -- boom! -- html! not to mention .mobi. and .pdf. _automatically_... -bowerbird