At 10:08 AM 2001-04-17 +0100, Matt Sergeant wrote:
>On Tue, 17 Apr 2001, Sean M. Burke wrote:
>> I've been working like a madman for the past few days, coming up with
>> a pod2xml and matching xml2pod. (Why? Because it's not there.)
>>[...]
>> module.)
>
>Umm, why? As the module authoring instructions on cpan say, why not help
>with the existing module?
Well, I considered just fiddling with your module so that it could to
xml2pod, and so that there'd be a DTD rigorously adhered to.
But first off: your module uses Pod::Parser, which I have little experience
with; I'm /much/ more used to Pod::Tree. (I've dealt with both, and /I/
find Pod::Tree more pleasant to deal with, but that probably just reflects
my bias towards parse trees, a` la HTML::Tree. Namely, dealing with
Pod::Parser gives me a migraine.)
And second off: I didn't want the whole thing your module does with <sect1>
elements, etc. There's nothing wrong with it, but I wanted to try a more
minimalist approach to the DTD, where there'd be nothing in the XML that
isn't in the POD, and vice versa: so POD has =head1, so my DTD has
<head1>...</head1>; POD has text paragraphs, so my DTD has <p>...</p>.
But POD has no directive or command for surrounding a head1 and all the
paragraphs after that until the next head1, so I didn't want any such thing
in my DTD. Analogously, POD has no directive or command for surrounding a
list-item-label (=item foo) PLUS the text in that list until the next
list-item-label. I thought of having <item>
<label>*</label><stuff><p>foo</p></stuff> </item> to represent "=item
*\n\nfoo", but that involved positing elements that are just not in the
POD, which is a slippery slope that I really felt like trying to avoid.
(And by saying that I wanted to try to be minimalist or whatever, I don't
mean that I presumed that that was where The Correct Solution would be -- I
mean that I was experimenting, giving it a whirl, and seeing how far I
could go with it and what the end product might look like.)
So I decided it'd be just simpler to start afresh with Pod::Tree and my new
idea of that the XML should look like.
You are, of course, welcome to adapt the xml2pod code from Pod::PXML (once
I release it-- I'm still fiddling with Latin-1/UTF8 things in it), and
construe it as useful for your xml2pod.
Most of the bother of me writing that bit was puzzling out all the
constraints on POD, and how to enforce them (e.g., a text paragraph mustn't
start with whitespace or =foo, mustn't contain any \n\n's, shouldn't be
0-length, and so forth); no single bit was terribly hard, but there was a
bunch of weird little things.
Incidentally, I don't suppose that my minimalist doctype is optimal for
every knowledge-extraction or rendering task -- not by a long shot! I
wanted a /mere/ notational variant of POD, thus (merely) making POD
tractable (bidirectionally) to XML tools. People concerned with optimally
semantic markup would code in something much much richer than pod; but if
they wanted to transform it into POD, they would be free to use XML tools
to do all the substantial work of transforming documents in their doctype
into PXML (turning a dozen semantically different elements into <c>...</c>,
for example), and then my module can do the last bit of work, turning PXML
into old skool POD.
--
Sean M. Burke [EMAIL PROTECTED] http://www.spinn.net/~sburke/
