Protocol for Handling the Removal of Features from 29500-3

[Rex Jaeschke]

During the revision of 29500-3, we're planning on removing some existing
functionality. While that is certainly allowed, I just wanted to point out
some options. Removing functionality from a standard might upset conforming
implementations that produce or expect that functionality. And while WG4
members might reasonably guess that there are no such implementations, I
doubt that we can actually prove that.

 

I see two choices:

 

1.       We can declare the functionality in question to be "deprecated"
(sometimes referred to as "obsolescent"), which serves notice that that
functionality might be removed in a future revision. We might also provide a
better/alternate mechanism. The idea here is to allow implementers to plan
for the changeover.

2.       We can remove the functionality, but we must note in the Foreword
that we have done so. We would mention the rationale for such removal in our
meeting minutes and prominently near the front of any Working Drafts (WDs)
we make public (which would be a great reason to have broad distribution of,
as well as multiple, WDs).

 

If we remove the functionality, what might happen when a future conforming
consumer that does not recognize the removed feature, is presented with such
a feature? A standard cannot speak to extensions implementers may provide.

 

I have no stake in this decision; I simply want to make sure that whatever
approach we chose has been thought through and is well documented. 

 

Assuming that we chose Choice 2 above, someone will need to write the
rationale, and the sooner the better. The rationale would need to be
approved by WG4 before we circulate publically the first WD (post-London
F2F), in which I'd include that rationale.

 

Rex

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20120424/45debfef/attachment.htm>