At 09:38 PM 2001-04-17 +0100, Matt Sergeant wrote:
>[...]I guess the biggest problem becomes you can't
>install both POD::XML and POD::PXML, because the two pod2xml scripts will
>conflict. That's obviously bad.
If I understand module-dist makefiles, the conflict arises only if I go and
put this line in the Makefile.PL:
'EXE_FILES' => [qw(pod2xml xml2pod)],
I didn't even know one could do that until now, when I looked at the
makefile for your Pod::XML. All this time I've been in the habit of just
leaving such programs in the root of the module's directory, and if people
copy them off into a directory in their path (freely renaming along the
way), fine, otherwise no big loss. However, I suppose people might like to
actually have these programs be installed. So I might as well call them
pod2pxml and pxml2pod, with a
'EXE_FILES' => [qw(pod2pxml pxml2pod)],
line in the makefile; and if people want to rename them, fine.
>> 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.
>
>Can you expand on the exact purpose of it though? I mean, XML editors
>suck, and pretty much the only decent thing you can do right now is render
>the stuff or process it somehow.
Yes, and "processing" can mean anything: spellchecking, concording,
querying, indexing.
Simply put, I want these modules to make it so that no-one /has/ to deal
with POD using any other Pod::* module, if they would prefer to deal with
it as XML.
And I think that enrichifying the tree you get out of a POD document is a
completely distinct task from /just/ expressing it as XML, and I don't want
to conflate two distinct tasks, especially where there's any number of sane
ways to do the latter bit.
If I were to read in POD and then emit XML that was in some way /more/ than
just a notational variant of the POD, then that does two things: that gives
the XML more syntactic complexity than the POD had -- complexity that the
POD got along fine without, and also complexity that is somewhat arbitrary:
i.e., there's more than one conceivable way to group parts of a list (to
name something that I spent some time puzzling over recently), and some are
better for some things, some are better for others. I fear that if I make
a choice that pushes toward representation more optimal for some purposes,
it will just obfuscate things for people who don't have that purpose in mind.
In other words, considering list-item groups, you could take this:
=over
...
=item Labelle->sing
=item Marmalade->sing
These methods gitchi gitchi ya ya here, mocca chocolata ya ya.
$sangit = Labelle->sing || Marmalade->sing;
...
=back
you can represent it, minimally, as this:
<list>
...
<label>Labelle->sing</label>
<label>Marmalade->sing</label>
<p>These methods gitchi gitchi ya ya here, mocca chocolata ya ya.</p>
<pre>
$sangit = Labelle->sing || Marmalade->sing;
</pre>
...
</list>
or more richly, as:
<list>
...
<item>
<labels>
<label>Labelle->sing</label>
<label>Marmalade->sing</label>
</labels>
<discussion>
<p>These methods gitchi gitchi ya ya here, mocca chocolata ya ya.</P>
<pre>
$sangit = Labelle->sing || Marmalade->sing;
</pre>
</discussion>
</item>
...
</list>
Both are good.
But if I declared the latter richer one to be what I want my pod2xml to
emit (and leaving up to that module the work of grouping the things
together) and my xml2pod to accept, then I've done something that's useful
for /some/ applications. (Like I can imagine a renderer happily wanting to
insert a bit more space after each <labels>, not after each <label>).
But that makes everyone /else/ grind their teeth when they see this mad
swarm of markup, because it means that the most common case, =item
foo\n\nbar, is no longer simply <item>foo</item> <p>bar</p>, but is instead
<item> <labels><label>foo</label></labels>
<discussion><p>bar</p></discussion> </item>, which is a bit much.
Alternately, you could make it so that one's doctype could allow for both
<item>foo</item> <p>bar</p> and <item>
<labels><label>foo</label></labels> <discussion><p>bar</p></discussion>
</item>, but I think that that's /worse/ than either, for everyone.
(Granted, if this were full SGML, I could say stipulate that <label>
implicates <labels>, but full SGML is something that I avoid because I've
never committed an indictable crime against humanity, and I don't want to
start now. Not that Pod::HTML2Pod couldn't be /prosecuted/ as such, but I
think that I could get off on grounds of PER SE IPSUM temporary insanity!)
So I figure if anyone wants/needs a doctype that has all the richness of
<item> <labels><label>foo</label></labels>
<discussion><p>bar</p></discussion> </item>, then it's up to them to
convert PXML into that doctype, or back, depending on which way they want
to go; but that Pod::PXML's existence at least saves them from having to
deal with parsing/producing POD itself.
That leaves PXML as no-one's favorite XML doctype, but a passable
purpose-agnostic interchange format.
--
Sean M. Burke [EMAIL PROTECTED] http://www.spinn.net/~sburke/
