Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
On Wed, Oct 04, 2000 at 03:42:57PM -0500, Jarkko Hietaniemi wrote: > > Any others? There are bugs in the RFC process. Now is the time to > > fix them. > > I don't know whether this is worth a separate improvement # but here goes: > > Too many RFCs live in a vacuum by not not explaining in enough detail > what is the problem they are trying to solve, RFC Improvement #6: Every RFC must contain a brief background describing the problem in enough detail for readers to understand what this RFC proposes to solve. Conciseness is preferred. Links to extended discussions are appreciated. > but instead go ahead and > pull new/backward-incompatible syntax and/or keywords and/or semantics > out of thin air. I hope we're done the first phase of RFC submissions, that aspect of RFC submissions should be behind us. > Call me an old curmudgeon Jarkko, you're an old curmudgeon. > but some > words towards backward compatibility, keeping proposed changes as > small and generic as possible (I think that's one of things that > epitomises perl: lots of cleverly interlocking small features or > feature sets) would have been nice before the launch of the RFC process. RFC Improvement #7: Every RFC must contain a discussion of migration and backwards compatibility, as appropriate. This includes non-internals areas such as licensing. New areas of effort may be excluded[*]. Keeping RFCs current is another bug in the process. Here's a possible fix: RFC Improvement #8: RFCs are patchable. This is to encourage RFCs to be kept up to date with a synopsis of discussion about a proposal, especially when the maintainer is too busy to keep updating an RFC. Process TBD. Z. *: OK, so we're losing formats, but Damian shouldn't need to write a backwards compatibility dissertation for each and every new extension to formats he comes up with (even though he could). Ditto on 'use Notation::Polish::Reverse;'
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
> Any others? There are bugs in the RFC process. Now is the time to > fix them. I don't know whether this is worth a separate improvement # but here goes: Too many RFCs live in a vacuum by not not explaining in enough detail what is the problem they are trying to solve, but instead go ahead and pull new/backward-incompatible syntax and/or keywords and/or semantics out of thin air. I know that one of the goals of the RFC process was to encourage bold and daring new ideas, but I must confess to oftentimes being one or more of scared/baffled/amused/sad when seeing how blithely people took to the task of bodly going where few have gone before, maybe for a reason. Call me an old curmudgeon but some words towards backward compatibility, keeping proposed changes as small and generic as possible (I think that's one of things that epitomises perl: lots of cleverly interlocking small features or feature sets) would have been nice before the launch of the RFC process. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
[Moving this discussion to -meta. See Reply-To.] On Wed, Oct 04, 2000 at 03:14:39PM -0500, Jarkko Hietaniemi wrote: > > I disagree. The RFC process is for generating ideas, not making decisions, > > nor is any author obliged to include ideas he/she doesn't agree with; > > that's why others can (or could) submit RFCs that contradict it, if they > > want to. The author is no more obliged to include opposing opinions in > > Not obliged, no. But not recording opposing views is like sticking > fingers in your ears and loudly chanting 'la la la la, my proposal > is good, pure and uncontested, la la la, la la la...' RFC Improvement #1: All updated RFCs must contain a CHANGES section. RFC Improvement #2: All updated RFCs must contain a synopsis of relevant discussion, including opposing views. RFC Improvement #3: All final RFCs must contain a discussion of why they are finalized. RFC Improvement #4: Each working group may define more stringent acceptance criteria for RFCs. -licensing doesn't care about including test plans, and -qa doesn't care about redistribution considerations. RFC Improvement #5: An working grouup chair can cause an RFC to be withdrawn from condideration if it is off-topic or simply rehashing old issues. This is to keep the brainstorm-to-proposal ratio close to zero when rampant brainstorming is not desired. Any others? There are bugs in the RFC process. Now is the time to fix them. A modified RFC process should be in place for Perl6, where it fits. And it should not be a process that generates 150+submissions/month of wildly varying quality. Z.
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
> I disagree. The RFC process is for generating ideas, not making decisions, > nor is any author obliged to include ideas he/she doesn't agree with; > that's why others can (or could) submit RFCs that contradict it, if they > want to. The author is no more obliged to include opposing opinions in Not obliged, no. But not recording opposing views is like sticking fingers in your ears and loudly chanting 'la la la la, my proposal is good, pure and uncontested, la la la, la la la...' > their RFC than the proposer of a bill in the House is required to include > contrary views. One doesn't necessarily merge two conflicting ideas to get -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
At 08:36 AM 10/4/00 -0700, Nathan Wiger wrote: >I'm sorry, I was gonna bite my lip, but I've gotta say: Freezing RFC's >like this when the following is true: > > > A lot of good, heated discussion was generated on the mailing lists. The > > majority seems against using XML-DTD documentation, but granted there are > > deficiencies in POD. > >Is absolutely, 100% against the entire idea of the RFC process. I disagree. The RFC process is for generating ideas, not making decisions, nor is any author obliged to include ideas he/she doesn't agree with; that's why others can (or could) submit RFCs that contradict it, if they want to. The author is no more obliged to include opposing opinions in their RFC than the proposer of a bill in the House is required to include contrary views. One doesn't necessarily merge two conflicting ideas to get one that's better than both any more than you can cross a goldfish with a Jacquard loom and get an underwater basket weaver. Better to let each stand independently. [In case it needs saying, this is absolutely nothing to do with my views on the RFC in question.] >But freezing something that everyone's against is a waste of everyone's >time. Sorry, but it is. At least one person appears not to be against it. In any case, Nat said earlier that freezing doesn't mean discussion is over, nor that the RFC can't be changed; just that the author has indicated that they don't (currently) plan to make any more changes. >And yes, I've retracted 7 of my own RFC's because the community was >against them. The whole point of this Perl 6 process is to develop a >language that the community thinks is the right direction, right? No, the idea is to be an extension of Larry's creative thinking process. Neither of us is deciding what goes into Perl 6, and neither is the community - I hope. Larry is. Languages designed by committees or votes don't work. I want a Perl that's the product of the vision of the same mind that generated the one I love, along with whatever help he wants to accept from the rest of us. Understand that I do not intend to belittle the contributions made by anyone from the rest of the Perl pantheon on downwards; I just believe Perl design is more art than science. A brainstorming process can be wonderfully enhanced by the introduction of contradictory or even nonsensical ideas. Not that I would have intentionally done so myself. But great ideas have sprung from the unorthodox thoughts provoked by such things. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
On Wed, Oct 04, 2000 at 12:18:22PM -0400, Buddha Buck wrote: > > Do you expect that your 7 retracted RFCs to be looked at by future > developers? Even if they had good, but unpopular, points to make? Or do > you expect that once retracted, they will be ignored? Mostly. There are some core developers we have yet to meet, and some core developers who have yet to look at the Perl sources. For future contributors, retracted RFCs demonstrate why some ideas are incredibly unperlish. And that helps keep Perl perlish, instead of adopting every feature from every other language out there simply because they exist. Z.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On 04 Oct 2000 18:43:43 +0200, Johan Vromans wrote: >POD is not suitable for producing books. It can be used, however, to >provide the information that a (human) typesetter can turn into a >printed book. If a typesetter knows enough with just the POD, it is possible to completely typeset the entire book automatically. I'm not saying that the standard tools provided with Perl, are enough. -- Bart.
Re: RFC 357 (v2) Perl should use XML for documentation insteadofPOD
Nathan Wiger, at 09:56 -0700 on Wed, 4 Oct 2000, wrote: > I suspect the fate of this RFC with be a "veto", and it will get just as > ignored as if it had never existed. I would argue there exists an important difference between a 'veto' ignore, and a 'retracted' ignore. A 'retracted' ignore means that there is no reason whatsoever to consider this RFC ever; there is something 'better' out there, or there is some fundamental flaw or contradiction in it to prevent its coming-to-be. It is 'invalid' for some reason. A 'veto' ignore means that at the present time, this RFC does not have support for it. However, in the future, given better arguments, or a sway in the universe of Perl, the RFC might be re-looked at, and we can be re-reminded of the arguments for and against the issue. It is still a 'valid' RFC. (Please don't take this to mean I'm still really really trying to push the RFC; the above I meant to write concerning RFC's in general). -- Frank Tobin http://www.uiuc.edu/~ftobin/
Re: RFC 357 (v2) Perl should use XML for documentation insteadofPOD
Nathan Wiger, at 09:56 -0700 on Wed, 4 Oct 2000, wrote: > This is *exactly* why I suggested that the RFC be renamed and try to > work within the constraints of keeping POD. In doing so, it could add > really useful input. Otherwise, it will likely be ignored just like it > was retracted now. And I'd bet that the title as-is already causes many > to skip over it as "not gonna happen", causing its points about POD to > be missed completely. Renaming the RFC would mean me having to present a whole different argument; the original argument was to replace POD with XML-based notation, period. I'm not going to try to try to take all the comments generated over the past few days and try to munge them together to come with a 'new' RFC. I felt retracted RFC's were those which were superseded, or 'impossible'; not just those which are highly unpopular. The frozen state, I felt, means I don't feel there was much more meaningful input to improve the quality of the RFC. Of course, my interpretation of these values for the Status: field is not necessarily the best one. As Buddha noted, as I originally intended, I requested comments, got them, summarized, and concluded. -- Frank Tobin http://www.uiuc.edu/~ftobin/
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
David Grove <[EMAIL PROTECTED]> writes: > > We did this for the camel. Which, I remind the world, was > > written in pod. > > seriously, that impresses me. POD is not suitable for producing books. It can be used, however, to provide the information that a (human) typesetter can turn into a printed book. You can also do this with HTML, but HMTL is much harder to write. XML is unwritable. -- Johan
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
Philip Newton wrote: > > I'm not sure that this bit of the third quoted paragraphs is correct: > "It's quite possible that switching to an XML docset produces a beautiful, > unmaintained set of documentation that is of no use to anyone." I think > it's more likely that switching to an XML docset produces very little > documentation, and what there is will be of widely varying quality. Not > everyone will want to expend the effort involved to plan out, carefully, > their document structure and produce lovely docs. I am of the opinion that any documentation which requires, or at least would significantly benefit from, the use of something heavy like SGML is best done OUTSIDE THE CODE. There's no reason you can't have document files accompanying the perl code files, for gosh sakes. -- John Porter By pressing down a special key It plays a little melody
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Wed, Oct 04, 2000 at 03:15:22AM -0600, Tom Christiansen wrote:
> >POD, presumably. Or maybe son-of-POD; it would be nice to have better
> >support for tables and lists.
>
> We did this for the camel. Which, I remind the world, was
> written in pod.
What kinds of things got added for the camel?
Personally, my largest complaint with POD is that lists eat far too
much vertical whitespace. It takes four lines to write a one line
checklist item.
SDF does lists in a simple fashion that is both easy to read and write:
* Item one of a bulleted list.
* Item two.
* Item three.
. Item one of a numbered list.
^ Item two.
. Start of a new numbered list.
This breaks POD's use of blank lines as paragraph separators, however.
Perhaps POD could get a =list directive? (=over is evil, IMO. You
shouldn't be specifying the number of columns to indent ("=over 4"),
you should be specifying logical indentation depth.)
=list
* Item.
* Item.
* Item.
=endlist
- Damien
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On 2 Oct 2000, at 21:04, Adam Turoff wrote: > If you want to use XML, Latex, Texinfo or raw *roff for your docs, > then by all means do so. Understand that Perl can't be made to > magically ignore embedded Texinfo, and Perl contributors realistically > can't be made to understand/patch/correct multiple markup formats. I believe Perl can still embed raw *roff. IIRC, in Perl 1, POD hadn't been invented, and Larry used raw *roff inside Perl code. However, I don't think this practice is encouraged these days ;) Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]> I appreciate copies of replies to my messages to Perl6 lists.
RE: Perl already allows XML for documentation (was Re: RFC 357 (v1) Perl should use XML for documentation instead of POD)
On 2 Oct 2000, at 10:35, Garrett Goebel wrote: > From: John Porter [mailto:[EMAIL PROTECTED]] > > > > It would be very detrimental to perl's performance to have to do an > > XML parse of every input source file. > > if the parser can skip between: > > =pod > > =cut > > it can certainly be made to skip between: > > > Skipping between =pod and =cut is a lot easier than between and when you are reading a line at a time; you can simply strcmp them and not have to worry about what happens if there's other stuff before and after the tags. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]> I appreciate copies of replies to my messages to Perl6 lists.
Re: RFC 357 (v2) Perl should use XML for documentation insteadof POD
> Retracting would have been easier, but could very well be seen as giving up > on pointing out PODs deficiencies. Pointing POD deficiencies is fine. But the fundamental thrust of the RFC is still "replace POD with XML". That's why I even noted the alternative names and corresponding emphasis in my previous email, as a way to make it more productive. I suspect the fate of this RFC with be a "veto", and it will get just as ignored as if it had never existed. So the analyses it contains of POD will be skipped over, and repeated verbatim in future discussions. That's too bad. > The RFCs are not the end-all of Perl development. As you stated, they are > "Requests For Comments", and not every frozen RFC will get accepted by the > community. Well, this might point out an additional flaw in the process, or at least misunderstanding. I always thought these were ultimately suggestions for Larry, for Larry to sort out, *after* the community (those on p6*) had consolidated input. That is, the finished RFC's would be delivered with the confidence that at least a good proportion of the populace felt that way. I have not seen that with this RFC. I counted 2-3 people who supported migrating to XML. Everyone else pointed out problems with POD, which would have been a great "fix POD" RFC on its own. But basically everyone on the list was against XML replacing POD, which is what the RFC says. And that's why, in its current form, it should be retracted. > Not every RFC -can- be accepted by the community; I think there > are some pairs that are mutually exclusive, and intentionally so. This is true, but should (hopefully) only occur when people back both, and it comes down to Larry having to decide. Witness RFC 152 vs. RFC 223, which have opposing ways of implementing self(), both of which had strong proponents. But then, witness RFC 171 vs. RFC 218, which address what "my Dog $spot" is supposed to do. The former was retracted because people liked RFC 218 better. This is a great example of the process working. > Do you expect that your 7 retracted RFCs to be looked at by future > developers? Even if they had good, but unpopular, points to make? Or do > you expect that once retracted, they will be ignored? No, I hope they are ignored, until somebody says, "Look, we already talked about the 'list' keyword - go see RFC 175 for why it doesn't work". Eventually, RFC's are going to move into a third state, per Larry's decision on them. At that point, if this RFC is rejected, it will be ignored just as much as one that was retracted in the first place. This is *exactly* why I suggested that the RFC be renamed and try to work within the constraints of keeping POD. In doing so, it could add really useful input. Otherwise, it will likely be ignored just like it was retracted now. And I'd bet that the title as-is already causes many to skip over it as "not gonna happen", causing its points about POD to be missed completely. -Nate
Re: RFC 357 (v1) Perl should use XML for documentation instead ofPOD
On Sun, 1 Oct 2000, Adam Turoff wrote: > POD has three mighty significant advantages over XML: > - it is easy to learn > - it is to write > - it is easy to ignore, if you're spelunking for Perl code > Try and do that, when interferes with syntactically. [snip] > Moving towards a system that adds any friction to the documentation > process is a *>HUGE<* mistake. [snip] > Increasing author effort may make for more beautiful documentation > for the reader, but it also inhibits authoring content in the first > place. It's quite possible that switching to an XML docset produces > a beautiful, unmaintained set of documentation that is of no use > to anyone. I like these three paragraphs especially (because I agree with them). One of the stated(?) goals of POD was to have a syntax so simple that it's easy to do documentation. Everyone knows that programmers hate to document stuff. So by providing them with a fairly minimal framework, the amount of learning effort and the number of decisions required are fairly small, increasing the chance that code will be documented. If people don't have to worry about what should be fixed and what not (relying instead on smart POD translators), they'll be more likely to go ahead an write. I'm not sure that this bit of the third quoted paragraphs is correct: "It's quite possible that switching to an XML docset produces a beautiful, unmaintained set of documentation that is of no use to anyone." I think it's more likely that switching to an XML docset produces very little documentation, and what there is will be of widely varying quality. Not everyone will want to expend the effort involved to plan out, carefully, their document structure and produce lovely docs. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]> I appreciate copies of replies to my messages to Perl6 lists.
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
At 08:36 04/10/2000 -0700, Nathan Wiger wrote: >This RFC should either be retracted, or revised into: > > POD to XML translation should be easier On this subject, I have notes about a Pod::SAX module that would make pod2xml much easier. If I have time to implement it I'll do it, but I can't tell when that will be. If anyone wants the meagre notes that I have to start working on this, I'll be glad to provide them. -- robin b. Heisenberg might have been here.
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
At 08:36 AM 10/4/00 -0700, Nathan Wiger wrote: > > =head1 TITLE > > > > Perl should use XML for documentation instead of POD > > > =head1 VERSION > > > > Status: Frozen > >I'm sorry, I was gonna bite my lip, but I've gotta say: Freezing RFC's >like this when the following is true: > > > A lot of good, heated discussion was generated on the mailing lists. The > > majority seems against using XML-DTD documentation, but granted there are > > deficiencies in POD. > >Is absolutely, 100% against the entire idea of the RFC process. They're >"Requests for Comments". The comments received were overwhelmingly "This >is a Bad Idea". I gotta disagree. You'll note that he requested comments, got comments, and reported the tone and results of those comments in v2. Also, he made no other changes, and got v2 in place 4 days after v1, 2 days after the 1 October deadline. Would you have been able to make the sort of revisions you are suggesting below under that sort of time pressure? I know I wouldn't, based on my experience with my RFCs. Retracting would have been easier, but could very well be seen as giving up on pointing out PODs deficiencies. >This RFC should either be retracted, or revised into: > >POD to XML translation should be easier > >or > >POD should be made more flexible > >or > >Here are some deficiencies in POD that need to be fixed > >But freezing something that everyone's against is a waste of everyone's >time. Sorry, but it is. > >And yes, I've retracted 7 of my own RFC's because the community was >against them. The whole point of this Perl 6 process is to develop a >language that the community thinks is the right direction, right? >Sometimes that means accepting that no matter how much you like your >idea, other Perl'ers don't. The RFCs are not the end-all of Perl development. As you stated, they are "Requests For Comments", and not every frozen RFC will get accepted by the community. Not every RFC -can- be accepted by the community; I think there are some pairs that are mutually exclusive, and intentionally so. Compare RFC 126 (Ensuring Perl's Object Oriented Future) and RFC 137 (Perl II should not be fundamentally changed). At most one of those two will "win", since they have different philosophies for Perl6 OO development. Hopefully Perl6 will be the real winner. Do you expect that your 7 retracted RFCs to be looked at by future developers? Even if they had good, but unpopular, points to make? Or do you expect that once retracted, they will be ignored? I think retracted RFCs -will- be ignored. Better to have a frozen RFC that says "no one liked my solution, but most agreed the problems existed", that gets those problems documented and -looked at- than to have the problems detailed in something most will summarily ignore. >-Nate
one major flaw in the RFC processn
> > Status: Frozen > > I'm sorry, I was gonna bite my lip, but I've gotta say: Freezing RFC's > like this when the following is true: > > > A lot of good, heated discussion was generated on the mailing lists. The > > majority seems against using XML-DTD documentation, but granted there are > > deficiencies in POD. > > Is absolutely, 100% against the entire idea of the RFC process. They're > "Requests for Comments". The comments received were overwhelmingly "This > is a Bad Idea". Exactly. One major gripe I had and still have with the RFC process is that many authors equated RFCs as their very own pet projects which shall not be criticized in any form, state, or manner. Pointed out flaws and problems were not recorded down in the RFCs. I admit that my idea of healthy RFC process may not be shared by everyone and that we certainly did not specify how RFCs should be maintained. It's possible to overboard in the other direction, too: some RFCs tried perhaps too hard to embrace every little idea or comment thrown at their direction, resulting in bulky monstrosities, where featuritis is not only creeping but leaping. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 288 (v2) First-Class CGI Support
[Iain, I'd really appreciate it if you'd copy me on your replies to my posts. The volume is so high that I don't always get time to grovel through the digests in a timely manner.] On Sat, 30 Sep 2000, iain truskett wrote: > * Philip Newton ([EMAIL PROTECTED]) [30 Sep 2000 02:47]: > > However, the protocol on incoming headers is mainly significant > > between the HTTP user agent and the web server; once it gets to me, I > > don't care about the protocol any more -- the web server took care of > > that already. So the input headers can be unordered for all I care. > > For all your care, yes. Others may have different requirements, and > those requirements may change with new HTTP revisions. Fair enough. Which is why I tried to indicate that these were my needs I was stating. > > Again, I don't do CGI much -- there may be people who want the exact > > headers in the exact order. For me, knowing what the "User-Agent:" > > header and what the "Accept-Charset:" header (or whatever) say is > > sufficient, and I don't care whether one is before or after the other. > > Again --- that's you. This RFC is for all of us. At the very least, > include the opposing arguments so that Larry can see that there were > multiple factions. I include opposing arguments? I'm not the one writing the RFC that Larry sees. Do you have me confused with someone? I was just presenting my side of the argument for the RFC author to notice (hopefully); it's up to him to agree or disagree, and to include my side in the RFC or not. > > > Having a %HTTP and a @HEADERS is rather simplistic and not really > > > that accommodating for potential modifications to the protocols for > > > HTTP and CGI. > > > Possibly true. However, I believe that headers will still follow the > > "Key: Value" style, so @HEADERS should not be affected (if the > > programmer has to specify the order, that is -- then she can still do > > so in the future). And %HTTP may not need to be ordered. > > So you're saying that @HEADERS (the output one) can quite happily be > ordered (which it is by default) or unordered, erring on the side of > ordered; while on the other hand you're saying that %HTTP (input) may > not need to be ordered (just as it may need to be ordered), erring on > the side of unordered. No, that's not what I was saying. I think the output headers should be ordered, while the input can be ordered or unordered, with no preference. If it's more useful for them to be ordered (for programs that rely on the order, perhaps because they want to deal with the CGI or HTTP spec rather than leaving that up to the web server), that's fine with me. However, in that case, we can't use a(n untied) hash. A hash would be nice, because it gives you random access and an easy way to query exists(); however, if ordering is desired, some other method would have to be used. Which I'm fine with. > Don't take this the wrong way, but you are being hypocritical in your > treatment of input and output headers. Maybe you misunderstood me :). If not, please point out wherein you believe my hypocrisy lies. > > > > In other words, the input has an order (the order in which the > > > > user- agent sent the headers), but I'm not necessarily interested > > > > in it (frequent CGI programmers may have different needs); > > > > > > Precisely. So theoretically, we should provide for both situations. > > > Well, if you provide it ordered, you *are* providing for both > > situations -- those who want it ordered have it ordered, and those who > > don't care about the order will be happy, too. After all, I didn't say > > "I explicitly want it unordered" or "ordered according to the hash of > > each header field". > > But a %HTTP is the only variable you're giving us, which (by its nature) > is unordered. *I* am not giving you anything. I think you have me confused with the author of the RFC again. I agree with you, though, that hashes are unordered, and that if order is desirable, this interface is not very useful. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
On Wed, Oct 04, 2000 at 08:36:32AM -0700, Nathan Wiger wrote: > against them. The whole point of this Perl 6 process is to develop a > language that the community thinks is the right direction, right? Really? I thought the whole point of this was to develop suggestions to put to Larry, for him to consider and evaluate. In a perfect world, "the community" can agree on a "right direction", and we'd be following that. As we've seen, not only is it difficult to agree, but even agreeing on a direction is no guarantee that it's right. -- "I find that anthropomorphism really doesn't help me with a place full of bugs." -- Megahal (trained on asr), 1998-11-06
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
> =head1 TITLE > > Perl should use XML for documentation instead of POD > =head1 VERSION > > Status: Frozen I'm sorry, I was gonna bite my lip, but I've gotta say: Freezing RFC's like this when the following is true: > A lot of good, heated discussion was generated on the mailing lists. The > majority seems against using XML-DTD documentation, but granted there are > deficiencies in POD. Is absolutely, 100% against the entire idea of the RFC process. They're "Requests for Comments". The comments received were overwhelmingly "This is a Bad Idea". This RFC should either be retracted, or revised into: POD to XML translation should be easier or POD should be made more flexible or Here are some deficiencies in POD that need to be fixed But freezing something that everyone's against is a waste of everyone's time. Sorry, but it is. And yes, I've retracted 7 of my own RFC's because the community was against them. The whole point of this Perl 6 process is to develop a language that the community thinks is the right direction, right? Sometimes that means accepting that no matter how much you like your idea, other Perl'ers don't. -Nate
RE: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Wednesday, October 04, 2000 4:15 AM, Tom Christiansen [SMTP:[EMAIL PROTECTED]] wrote: > >POD, presumably. Or maybe son-of-POD; it would be nice to have better > >support for tables and lists. > > We did this for the camel. Which, I remind the world, was > written in pod. > > ''tom Uh... wow seriously, that impresses me. With that I reiterate my personal conclusions that playing too much funk with POD would be a disaster (including moving to something completely unpodly, like XML). Tom... wow. Is there anyway I could get the source for perusal? I'll supply O'Reilly with a copy of my book receipt to show that I own it. I want to see this in action.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
Garrett Goebel wrote: > From: Peter Scott [mailto:[EMAIL PROTECTED]] > > > > As I said earlier, why don't we just define a syntax for > > *anything* to be used as an extension language, and let > > the, er, market decide? > > Peaceful coexistance... what a concept. Sounds to me like the real issue is that writing pod converters is harder than it ought to be (rather like the situation with XS). I think most people don't realize that they can write a converter if they want to. -- John Porter By pressing down a special key It plays a little melody
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Wed, 04 Oct 2000 03:15:22 -0600, Tom Christiansen wrote: >We did this for the camel. Which, I remind the world, was >written in pod. You, masochist. (duck, and run) -- Bart.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
>POD, presumably. Or maybe son-of-POD; it would be nice to have better >support for tables and lists. We did this for the camel. Which, I remind the world, was written in pod. ''tom
