Re: [p5pod] [RFC ??, v1] =also for|begin|end POD commands

[Marek Rouchal DAT CAD HW Tel 25849]

On Thu, 3 Aug 2000, Brad Appleton wrote:

BA>Besides, I think there is still need for a Pod::Translator
BA>of Pod::Compiler module that uses (or is subclassed from)
BA>Pod::Parser to be the *real* base parser that people use (the
BA>one that actually knows the commands, just not necessarily
BA>the output format). I think putting =also in this new module
BA>instead would be a much needed first step to making a much
BA>more useful Pod2Xxxx base module that safely assumes it is
BA>used exclusively for translating perlpod-compatible commands
BA>into some output format (unlike Pod::Parser which simply parses
BA>into commands and paragraphs and prase-trees without knowledge
BA>of the meaning of them).

I'd like to assent to this idea. While coding a new POD to HTML converter
(MarekPodHtml-0.41) and starting with POD to MIF (FrameMaker), I found
that much of the code is reusable.
An ideal Pod::Compiler would - very much like the existing
Pod::Checker - extract node (=head, =item, X<...>) information from a
given POD that serve as link destinations. A Pod::Translator would read a
POD and build an object tree. By making use of Perl OO features the
individual objects (Pod::head, Pod::list (with Pod::item kids),
Pod::paragraph, Pod::verbatim etc.) would only need an appropriate 
"translate" method that would be filled with the guts of the destination
format. Every object would also have an "as_pod" method for
re-constructing POD format and an "as_text" method for rendering its
contents in plain text (important for links, TOC, index). There is a
Pod::Tree module out there that might serve as a basis for
this.

Coding this would also include rewriting the perlpod manpage.

I certainly would like to volunteer for coding such modules, but I have no
idea when there'll be time for this.

My 2c...

-Marek