[rfc-i] Alternatives to 'deprecated' in xml2rfc v3

Julian Reschke julian.reschke at gmx.de
Tue May 6 09:25:49 PDT 2014

On 2014-05-06 18:14, Dave Crocker wrote:
> ...
>> Exactly. It means "you can still use it, but it might be gone in the
>> next revision".
> Well, that certainly makes clear the issue here.
> Basically, some of you are indulging in a desire by some others (maybe
> more than just me, but maybe not, I can't tell) for backward
> compatibility, but really don't want to indulge it and are threatening
> to remove it in the future.

The idea is to remove certain constructs only after a better replacement 
has been available for some time.

> Over the course of Internet development, specs that make predictions
> about the future are almost always wrong.  So avoid the temptation, even
> in underlying philosophy.
> The point behind backward compatibility is to retain functionality, not
> merely to tolerate it temporarily.  If there is a compelling reason to
> break it, then make that case.  Don't threaten it for the future.  When
> the arguments are compelling, invoke them and apply them.  Until then,
> embrace backward compatibility.

Again, see above. Removing features right now means that there is no 
transition period. Is this really what you want?

> As of now, there is a set of vocabulary that will be permitted in input
> versions but will not be in the canonical version.  Use of the extra
> vocabulary will be translated as part of submission, into forms that
> conform to the stricter canonical version.

We can certainly argue about that aspect. It may be caused by confusion 
between processing instructions (which are not part of the xml2rfv 
language), and elements we just want to get rid of later on.

> ...

Best regards, Julian

More information about the rfc-interest mailing list