All the Perl that's Practical to Extract and Report

Pod as shorthand for XML

TorgoX on 2002-01-04T08:58:19

All are invited to ponder my ramble on the incomplete state of my ideas on expanding Pod ever so slightly so that it can serve as a notational variant of XML. (The first few paragraphs appeared here a few days ago, more or less.) I've sort of run up against a few problems where I see several solutions, but am not sure which is best.

POD parsing

Matts on 2002-01-04T10:01:37

I think the best idea in those threads is ziggy's idea to use SAX as the canonical representation of POD. It was always the idea of the Orchard project to make orchard nodes the canonical representation of everything, but orchard nodes turned out to be too complex to install, so we ended up with hashes in PerlSAX2, which isn't so bad (albeit a bit memory expensive). Anyway, what I'm suggesting is you follow the PerlSAX2 node structure and event model, and we can then very easily write XML output or HTML output or whatever using the growing set of SAX tools out there.

Aside from all that, which wasn't really what you asked, I'd say that the ideas are pretty good, save for one factor - the tag re-definitions have to be in the source pod file. This might be considered a pain for many people. Also, there are only so many single-letter tags you can write, which is something that might need careful consideration. What if you override L<> by accident, and then somebody uses it later? Finally, the tag re-definition thing still doesn't give us well defined tag metadata, like is needed for proper hypertext links.

I don't envy you trying to sort this out :-)

My uses for equivalences

jjott on 2002-01-04T16:00:33

I guess the only thing I don't get is the notion of being about to override tags for certain effects that will be placed within the actual POD itsself.

My perspective is one of writing a module. I don't think about HTML, DocBook, or whatever final target when I am writing it. I am just thinking about what I need to express and trying to do it as consistently as possible! If the DocBook user wants to have certain tags exchanged for something else would this not be a feature of the pod2docbook?

On the other hand - if there are more sanctioned tags for various things - that's cool. Then maybe my POD would be even better. As of now I'm not entirely happy with what POD does to my code.

Would you allow me to do something such as make an equivalence for not only rendering tags but content as well?

=equate D "I<Default:> $\n"

=equate R "I<Returns:> $\n"

D<blort>
R<foo>
becomes
I<Default:> blort

I<Returns:> foo
Obviously you cook the syntax how ever you want - just the idea I wanted to express. :)

In any event, what I see you thinking about should make your parsers a lot more flexible and reliable. Good for you!

Re:POD parsing

ziggy on 2002-01-04T16:44:31

I don't envy you trying to sort this out :-)
Me neither. :-)

I've been wrestling with this in isolation for about a year now (I need to refill that bottle of daily tuit supplements), and Sean is really hitting the problem head-on. Kudos, Sean.

What I've been fixated with is the idea of adding new linguistic constructs to Pod. The critical path here is first getting a better event-driven parser that simply parses Pod at the syntactic level without getting into the semantic meaning of Pod constructs. I've fired off a response to Sean's post that describes the nature of the problem space (Pod is both a syntax and a formatting language, not structural markup), and some ideas on how to fix it (=use blocks that force the formatter to pull in Perl modules which recognize new tags and implement their semantic behavior).