Hello Sean and *,
you may want to hava a look at Pod::Compiler. It basically does what you
have in mind, altough the tree it creates is not XML but a set of Pod::*
objects defined in Pod::objects. But this could be changed quite easily
(...if I had enough time for that, sorry to say so). But perhaps someone
could pick up what I started there? Or at least reuse some of the code by
cut&paste.
I have some doubts whether the approach I have taken (i.e. to have a
separate object type for each possible Pod construct) was the most
appropriate. I can very well imagine to have a uniform type of container
object (i.e. a XML tag), and define the actions dependent on the tag
type. Not much of a difference in fact. The idea why I chose the other way
was to have the ability to write
$obj->some_method();
any time and have the OO mechanism chose the right code rather than
if($obj->type() eq '...') {
$obj->some_method();
}
But that's mainly cosmetics.
The next major issue however is to decide whether this compiler/tree
builder should use Pod::Parser or have its own Pod parsing frontend for
performance reasons. I don't know.
Cheers,
Marek
SMB>The solution that most appeals to me currently, is to make this
SMB>hypothetical module take Pod as input, and spit out XML as output, which
SMB>the author of a Pod processor would then direct to whatever Pod parser he
SMB>prefers. This obviates most of the above-mentioned problems.
