On Sun, Dec 09, 2001 at 11:29:08PM -0700, Sean M. Burke wrote: > The solution that most appeals to me currently, is to make this > hypothetical module take Pod as input, and spit out XML as output, which > the author of a Pod processor would then direct to whatever Pod parser he > prefers.
While this approach does have some advantages, I agree with Stas that it creates too many problems. If some Pod->XML translation becomes the canonical implementation of a POD parser, then might I suggest a middle ground? Write a canonical POD parser that generates SAX events. That will please the folks who (1) want an XML rendering and/or (2) want event-based parsing. For those who want tree based parsing, there's always (1) Pod::POM, and (2) the option of creating an DOM tree from SAX events. That removes the need for installing an XML Suite just to process POD documents, but provides enough support for those who want to do so. The full POD->XML conversion is as simple as installing XML::SAX::Writer and using that as an output filter. The only disadvantage here is that while POD parsing would become less idiosyncratic (Pod::Parser is rather, um, unique) it would become more complex for the newbie (I've taught SAX parsing before, and it takes a while to grok the idea of events and callbacks). Considering the problem domain, I don't think this is an insurmountable disadvantage. Z.
