On Tue, October 11, 2011 9:53 am, Marcello Perathoner wrote:
On 10/11/2011 05:18 PM, Alex Buie wrote:
This is great, and I would love if we could have ZML be one of the allowed master formats, although I'm aware there's a bit of history there... http://www.z-m-l.com/
If you search the archives you'll find a post I made years ago about why this particular `language´ is not suited for ebook production.
Here's the full story about the proponent of that `language´:
http://www.gnutenberg.de/pgtei/0.5/examples/bowerbird/poo.html
Now Marcello, there is no need to resort to ad hominem. The fact of the matter is that even if BowerBird had consistently behaved in an exemplary and respectful fashion, z.m.l. is still inadequate as a markup language. Part of the problem is that we have no real specification of what z.m.l. /is/. BB has provided tons of "examples," (some of which are now inconsistent as apparently the language is still evolving) but no definitive declaration of what the language allows, and disallows, and how the elements are to be used. This is why I have dubbed z.m.l., SML -- Spousal Markup Language: there are rules, but you have to figure them out on your own, and they are subject to change on a whim. The original PG philosophy was that the text was the only thing that mattered, and all markup was superfluous. It quickly became apparent that at least emphasis needed to be indicated and so it was decided that italicized text would be indicated in UPPER CASE. Unfortunately, people began to discover that there were books which contained upper case text which was not intended as emphasis, so the /new/ standard became to use underscores to indicate italicization (only those of us old enough to have learned to type on typewriters will recall that the mechanical convention of typing was to underline what would otherwise be italicized). There are a number of constructs in other markup languages which z.m.l. does not support. BowerBird's response is that support for those constructs is unnecessary as e-books simply do not require them. This is, of course, the same argument as the one that /all/ markup is unnecessary, the line is simply drawn in a different place, and BowerBird becomes the ultimate arbiter of what is, and is not, needed in e-books. It's hard to know what markup will be necessary to preserve any specific work of literature. Thus, what is really needed is an eXtensible Markup Language, such as TEI, which captures everything we know about now, and can be extended when we encounter something new. z.m.l. fails on both these counts.