Publishable or Published?

[Bowerbird at aol.com]

todd said:
>   I apologize.  

oh, please.  don't apologize!  no need.
i _love_ a rugged exchange of views.
people regularly accuse me of flaming,
but actually, i'm as cool as a cucumber.


>   I was hoping though, that you could supply your own examples. 

well, i can, actually, even in my favorite arena of e-books:
most hand-held e-book-machines (and pda's) accept .html.

indeed, at this point in time, it's the rosetta-stone format,
so that's a place where .html is _not_ viewed in a browser.

and you're absolutely right.  theoretically, there is no real
_requirement_ that .html be viewed in a browser.  however,
given the complexities into which .html is being developed,
good luck to anyone building a non-browser that'll grok it.
(though i see some interesting stuff built on top of webkit.)
most of the e-book-machines only support a subset of .html.
(search google for "handheld html" to come up with the link.)

furthermore, people seem to have "accepted" the obligation
to convert their text into .html without too much of a fight.
many people convert project gutenberg's plain-ascii e-books
into .html, so they can put them on their handheld machines.

what i see out in the world, though, is a whole bunch of text
that is _not_ marked up.  and we seem to be generating text
at a much faster rate than we'll ever be able to mark it up.
(think of how much text yahoogroups generate every day.)

even if the text-to-html process can be automated greatly,
it's one step that (to me) seems to be largely unnecessary...

let's go back to those project gutenberg e-texts, for instance.
i agree entirely that, in the raw-ascii form, with text that is
one-sized and unstyled throughout, they are just plain ugly.

and as an e-book, a plain-text file leaves much to be desired.
the paper-books had headers that are big and bold, and it had
a table of contents and maybe footnotes and cross-references.

converting the e-text to .html allows us to restore all that.
but again, it comes at the cost of doing markup.  even if it's
automatic -- troublesome with the project gutenberg files,
as their formatting suffers from terrible inconsistencies --
it seems like an unnecessary step.  why not build a viewer
that understands the underlying structure of those e-texts,
and treats it accordingly?  so that's what i have been doing.

the _easy_ part was programming the e-book functionalities.
(easy for me, anyway, since i've created lots of e-book apps.)

the _hard_ part was writing the routines to snuff out all the
inconsistencies in formatting of the text across the library,
due to their creation by many different people over the years,
plus a very cavalier attitude about consistency from the people
who michael hart entrusted as caretakers developing standards.

while moaning about this task of resolving inconsistencies,
i whined that it would be _so_ much simpler if they had only
followed a few simple rules a bit more formally, and bingo,
that gave me the inspiration to develop such rules as "z.m.l.".
(the name was selected especially for the techies out there
who  can't seem to discuss anything that isn't an acronym.)

in the same way e-mail conventions are the base for markdown,
the most common formatting conventions in project gutenberg's
e-texts have served as the foundation for zen markup language.

the idea was that you could drop any project gutenberg e-text
on the app, and it would analyze the text, regularize formatting,
and present it correctly, with big and bold headers, for instance,
and an auto-generated hotlinked table of contents, with footnotes
treated in the expected manner, cross-references auto-linked, etc.

since the circle of people at project gutenberg was so _frosty_
about resolving to eliminate inconsistencies in future e-texts,
i felt there's no reason to help people who won't help themselves,
so i pulled back from that goal, and now promise only that my app
will correctly process text that's marked up _strictly_ in z.m.l.

i'd also been long familiar with se-text as a plain-text format, 
of course, plus people told me about markdown when it surfaced.
and the emergence and evolution of wiki-markup is inspiring too.
it seems people are now realizing that doing markup ain't fun.
it appears that our problem now is too many plain-text formats,
all of them just a little bit incompatible with each other.     :+)

anyway, to help beta-test my viewer-program (please! thanks!),
just send an e-mail to:  zml_talk-subscribe at yahoogroups.com
there's an old version saved in the files section there right now,
but i will have a new one within a week or so, if you wanna wait.

it's cross-platform, mac os7.x through o.s.x, win95 and up,
and i can even compile a linux version if someone wants to
test it for me from scratch.  (i don't have a linux machine.)

the program will shortly morph into a w.y.s.i.w.y.g. editor as well
-- because hey, that's the way it ought to be, don't you think? --
but for the time being, i'm plugging it just as a viewer-program.


>   Heck yeah!  Where's the PayPal link?

thanks, but my program is free, as in beer.
i wrote it as a present for michael hart,
in recognition of his pioneering efforts.

(by the way, where _is_ this free beer, anyway?
i always seem to have to pay for all of my beer!)

anyway, i'm sorry for the long posts just to introduce myself,
a friendly soul walking a parallel path very close to markdown.

-bowerbird