Sometime this summer while I was poking at perlpodspec, I wrote all the hard parts of a from-scratch Pod parser, to make sure it actually was implementable. But I tossed out my code out, since I assumed that I wouldn't actually need it -- since once perlpodspec was out, all the Pod::* authors would instantly leap up and make their modules compliant, right? Ahem.
Well, I probably didn't actually toss out the code, but I failed to name the files anything particularly meaningful or put it anywhere where I'd find it again, so I can't now find it on my vast hard drive.
Anyhow, I rewrote it from scratch, and doing that is never as tedious as I think. Indeed, as many people will tell you, tossing out your first try at something and rewriting, is usually a pretty good idea.
So now I have the hardest parts done of the new Pod parser module. It's downhill from here, just a bunch of busywork. The one remaining notable hurdle that I see, is the processing of L<...> codes. That's a mess and then some.
Re:Events, I beg of you
TorgoX on 2001-12-24T11:52:19
Yes, very much event-based, and with events getting fired in a sane order. (Because this is going to be a real parser, not a tokenizer.) It'll be either natively SAX, or natively something that's clearly a notational variant of SAX and for which I'd probably provide a simple SAX wrapper.Incidentally: originally I was going to make this be one black box where you pour Pod in one end and get XML out the other. (That's as opposed to a model where there's a whole Habitrail set of modules, each handling one little aspect of Podliness.)
But I was wisely prevailed upon to make this be mainly a module that fires SAX-like events, and then a little attachment module that turns those events into XML output.
