> 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
