Sean M. Burke wrote: > Now that perlpodspec has (hopefully) come to clear up some of the nastily > hazier aspects of Pod processing, I have starting wondering: what next? > And the answer I keep coming up with is this: writing a new Pod parser > module, basically from scratch, having it be perlpodspec-compliant from the > get-go, and having that be the canonical spec-compliant Pod parser. > > That begs the question: what should its interface look like? If it's > tree-based, what grammar would describe the trees it generates, and would > the node class interface look like? If it's event-based, what how should > its events differ from Pod::Parser's events? And how do I decide whether > to make it tree-based or event-based? One surprising thing I've learned is > that some people strongly prefer tree-based parsing systems, whereas other > people strongly prefer event-based parsing.
If you think about node based interface, please look at Pod::POM, which seems to do it in a nice way. > 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. This obviates most of the above-mentioned problems. > Specifically, people who like event-based processing would direct the > output stream to an event-based XML parser, and those who like tree-based > processing would direct it the tree-based XML parser of their choice. One > of the nice things about XML is that with it, there's only a notational > difference between processing models where every token generates an event, > and tree-based processing models. Moreover, this avoids having to actually > write and maintain a Pod-specific tree node class. Plus there's safety in > numbers, since everyone and their dog is processing XML these days, so It > Has To Work. > > Thoughts, anyone? I don't like the idea of creating the XML dependency for these reasons: - you must have the xml parser and reader available. if you distribute a system which relies on these conversions, you have to do loops in the air to make sure that your client will have an xml parser/reader that will work. - the xml parser may have perl and xml-c libs compat problems. - it adds unnecessary processing overhead. If you really want an intermediate format (which you never write anywhere, right), why not to keep it inside Perl? it'll be almost as blown up as XML (memory wise) and doesn't create new dependencies and will work for all older perl versions. If you really want you can freeze it to a file and then thaw it back into perl. In any case, what's wrong with having one parser that does it stream (event) based and another node/tree based? _____________________________________________________________________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
