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. 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? -- Sean M. Burke [EMAIL PROTECTED] http://www.spinn.net/~sburke/
