Iain 'Spoon' Truskett <[EMAIL PROTECTED]> writes: > On the other hand, it allows the authors to do what they like. The main > problem is that of redundancy. e.g. all my Pod will end up with > something like:
> =extend M module-name C,I > =extend N method-name C So why don't we instead agree to add M<> as markup for module names and N<> as markup for method names? Or do people feel like we run a major risk of running out of characters, or at least reasonable characters? Hm. I suppose I can see that. So the idea is to instead have a registry of XML-style names for attributes and then people can map the available single characters to the appropriate attributes in each POD file? > Hardly a mini-language. It's more a gracefully degrading syntax. It's a gracefully degrading syntax if we all agree on what M<> and N<> mean, but if M<> and N<> may mean things that are entirely different in each POD file, it feels to me like we're saying that everyone creates their own specialization of the POD language, which does feel like a mini-language to me. > It's not as if Pod is becoming pseudo-XML or anything. That's just the > representation used internally by Pod::Simple (and it has made my > writing of Pod::Simple::LaTeX very simple). I'm currently talking to Sean about Pod::Simple, since I took a look at it today and it didn't feel like it mapped anywhere near as well as Pod::Parser did for me. *wry look* I was hoping I'd fall in love with it, but I guess that didn't happen with Pod::Parser either. I'm just not all that fond of the XML document representation model. I much prefer something that's more native to POD with a paragraph as a primary object. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
