Adam Turoff, at 03:22 -0400 on Sun, 1 Oct 2000, wrote:
> POD has three mighty significant advantages over XML:
> - it is easy to learn
True, but XML is also easy to learn, and is more in-line with what the
user will probably already know, as covered in the RFC.
> - it is to write
True, but XML is not hard to write; if you want, you could make a real
simple DTD with very small tags.
> - it is easy to ignore, if you're spelunking for Perl code
> Try and do that, when <body> interferes with <STDIN> syntactically.
No reason there couldn't be a perl-style delimiter, with __*__.
> DocBook, my doctype of choice, comes with a handy-dandy 600 page reference.
> Terms like %qandaset.mix; and "entity reference" are far from easy to
> understand to the beginner. Especially when compared to '=head1' and
> '=head2'.
I'm not supporting DocBook. The concept of <h1>foo</h1>, I would guess,
is not that hard to grasp. Furthermore, the same syntax is used
consistently throughout the document; there is no separate syntax between
'headers' and 'body'.
> These are deficiencies in the POD language definition and the POD
> toolchain. It can be fixed by tweaking the definition of POD
> and writing better tools. It's not a reason to throw out POD
> entirely because something more hyped is available to replace it.
As covered, I'm worried POD will continually outgrow it's original design,
and become messier and messier.
> You must be kidding if you're seriously recommending XHTML as a
> replacement for POD.
I never stated I specifically supported using XHTML over pod; it was just
an example of a DTD.
> Moving to XHTML is one huge step backwards, because it is presentational
> markup instead of structural markup. XHTML+CSS as a structural
> model is a sick joke.
Ah, yes, we all know how great HTML with author-defined presentationss
per-instance-of-element are...
> Moving towards a system that adds any friction to the documentation
> process is a *>HUGE<* mistake.
If this is a valid argument, then why not just use comments insetad of
POD? XML does require some more work, granted. But it pays off.
--
Frank Tobin http://www.uiuc.edu/~ftobin/
