kovidgoyal said:
> You say that light markup (and you use markdown as an example)
> can handle anything by including xhtml which means a viewer app
> that is designed to view a lightweight markup language will have to
> parse xhtml anyway to display the file. In which case any viewer app
> advantage in using light weight markup is negated.
we seem to be talking past each other.
every light-markup system -- with the _exception_ of mine -- is
geared toward creating output formatted for an external viewer...
in some cases it's docbook, or .tei, or latex, but -- most usually --
it's (x)html, and it's aimed squarely at a web-browser as the agent.
so if you make a general statement about light-markup systems,
it will be interpreted with that understanding. if you want to say
they're "limiting", you're saying they're limiting _in_that_sphere_.
except markdown -- runaway market-leader in the genre -- has
_no_ limitations in that regard, since it can contain _any_ (x)html.
if you want to poke accusations at _my_ particular light-markup,
in the form of a claim that it cannot support every (x)html feature,
then you would be absolutely correct. but if that's what you meant,
then you should have said _that_.
and, in case i haven't said it before, or said it directly enough yet,
my particular system is aimed squarely at use for electronic-books.
i will support all the features needed by e-books, but nothing more.
and i'm aiming z.m.l. at _my_ viewer-program, not at a web-browser.
but heck yes, i can pass through (x)html just as good as the next format.
so if someone wants to use z.m.l. to target a web-browser, via the .html
conversion ability, then go ahead and include whatever (x)html you want.
so i'm still seeing absolutely no substance to your point. none at all.
but maybe we're still talking past each other... proceed if you wish...
> Incidentally I actually use markdown and have even contributed patches
> to the python markdown project
so then why did you say what you did, which was highly misleading?
you must have known it bordered on totally false when you said it...
> As for authors not wanting to learn markup. Those that are too lazy
> to learn markup will be too lazy to learn lightweight markup as well.
> They will demand a WYSWYG GUI to take care of the markup for them.
did you not read in this very thread where i said i'll give them wysiwyg?
> You have the attitude that creating a markup language that is
> just sufficient for all of todays needs is the right approach.
well, as i said above, the needs of _e-books_ in particular, and that's it.
> You'll then "add more features" as you see the need.
> But it's not easy to "add features" to a lightweight markup language.
well, i just disagree with you about the difficulty of adding features.
and since that's _my_ problem and not your problem, we don't need
to go back and forth about it. it's a "difficulty" i'm willing to handle...
but the fact is, i've done a lot of work up-front to make sure that
i was knowledgable about the features that i would actually _need_.
that's why i devised a test-suite. and i've lived with it for two years,
and i've convinced myself that it's sufficiently complete for the job...
(there _is_ stuff that might not be completely visible on its surface,
but i haven't yet put it in because i want to learn which observer is
smart enough to see the "shortcomings" and draw attention to 'em.)
moreover, i did the work of specifying the features that i demand of
my ideal e-book viewer-app, so i know what my format needs to do:
>
http://onlinebooks.library.upenn.edu...t=2004-01-08,3
given my preparation on both sides of the equation, i feel i'm covered.
i've also looked at a very large number of paper-books over the years,
so i'm quite confident i'm aware of the sphere of things that's needed.
> Case in point is markdown and how you have to
> jump to html for any advanced features.
i was years into development of z.m.l. before markdown even started.
and i am moving slower than they are, with more advance planning...
that means i can benefit from their experience, and i certainly have...
i also have the advantage that my scope is narrower than their scope,
in that my arena is electronic-books. at the same time, i have concerns
they do not have, including file-format interaction with my viewer-app.
so you really can't generalize from their experience to mine... sorry...
but i would also say you're misconstruing their situation just a little...
it's not my sense they had to "jump to html" for "advanced features".
i think they deliberately put in that option early, to retain simplicity.
> So yes, it is more effort to develop applications for
> authoring/converting/viewing a "heavy" markup language,
> but in the end its worth it.
hey, i'm glad you feel that way, so _you_ will bear the costs of that,
and _other_people_ -- perhaps even me! -- will accrue the benefits.
likewise, if other people are willing to pay the costs of heavy-markup,
then i have no objection to it. (except maybe a general dislike for cruft;
but, you know, if it gives me a ton of benefits, i can even live with that.)
it's only when _i_ have to pay the price of doing heavy-markup that i balk.
and, you know, i have been waiting for the heavy-markup advocates over
on the p.g. listserve to start marking up the e-texts for over 4 years now,
and they're still just as uncoordinated about the task as they've ever been.
indeed, they seem totally unwilling to do the job themselves, and instead
seem bent on trying to "convince" the p.g. volunteers to do it for them!...
needless to say, the volunteers aren't eager to pick up this complex task.
> To say that we must limit ourselves to a lightweight language
> simply because developing applications for a heavy language
> is too difficult, is ridiculous.
well, then, you know, maybe you should trot over to the p.g. listserves,
or maybe the d.p. forums, because they keep moaning the lack of tools
that would help 'em take on the complicated job of doing heavy-markup.
because you make it sound easy...
> Lightweight markup is a good fit for gutenberg, but little else.
well, yes and no. it's gonna be good for project gutenberg e-texts...
if i didn't believe that, i would not have put in several years of work...
and i certainly wouldn't be willing to convert the whole catalog myself,
and spend my time and energy on maintaining an independent mirror.
but i don't believe it'll be "a good fit" for "little else". indeed, i'm viewing
project gutenberg's corpus as mere "proof of concept" for a cyberlibrary
composed of the _tens_of_millions_ of books that google is now scanning.
i don't intend on maintaining _that_ myself, just giving them a good model.
> And even there, I suspect they'd have a hard time getting their digitizers
> to follow the rules.
are you reading my messages here? as i said before, most of the text in
almost all of the project gutenberg e-texts is _already_ in z.m.l. format...
that is, they are already "following the rules"...
there are usually a few inconsistencies in each one, which my routines
can find and fix -- automatically, for the most part -- so i'm satisfied...
now, of course, it would be far better if p.g. tracked down the glitches,
so _their_ versions would be completely consistent as well, but oh well,
at least i know mine will be. and other developers will learn that too...
> As far as creating modern digital books, there is really no reason
> to be restricted to a lightweight markup language. And note that
> I continue to call it lightweight, because that is precisely what it is.
perhaps you misunderstood... i just told you what _we_ call it, and why.
i don't really care what you call it. it doesn't really care what you call it.
and i don't care if you imply it is limited. or even if you say that directly.
as long as it does what _i_ want it to, the things _i_ consider necessary,
i will be happy with it. and i'm certain others will be happy with it too...
especially those authors who don't wanna waste any time doing markup.
> You say you want to maintain a mirror of gutenberg. An excellent idea.
> If you support export of gutenberg texts to HTML, I might even use it
of course i'll support conversion of my files to .html. and of course people
will use it. but they'll quickly learn that conversion is an unnecessary step,
because e-texts in the native z.m.l. format are a better e-book experience,
thanks to the high-powered z.m.l. viewer-program...
> And if you've developed a converter,
> do you mind releasing it to the public,
> so that we can use it to convert gutenberg texts
> and see how well it does for ourselves?
well, yeah, actually i _do_ mind "releasing it to the public".
i have no intention of releasing any source code, thank you.
but it's available for sale, with a price in the 6-figure range...
however, you will receive the _fruits_ of the conversion process
-- in the form of totally consistent e-texts in my z.m.l. format --
when i mount my mirror. but that'll be sometime down the line,
because part of that job involves reformatting of the front-matter.
and -- for the 4th time now -- if you want to "see how well it does",
then just visit the web-page that i gave up at the top of this page:
>
http://z-m-l.com/go/vl3.pl
>
http://z-m-l.com/go/zmldingus093.pl
the second of those two is a "live" converter, which you can use to
convert a project gutenberg e-text if you like. you'll have to clean it
up a bit first -- so that it's in z.m.l. format -- but then it'll work ok...
with, of course, the caveats i've given all along -- "in-progress", etc.
-bowerbird