Document Number: AUSTIN/52

Title: Aardvark processing and proforma responses

Revision Date: 2000-05-25

Source: Andrew Josey, Chair

Action: for review


Discussion document, on how we process aardvark, and
proposals for proforma responses:


Q. Many of the Aardvarks processed were rejected as 'out of scope' or
a response was given as ' this would need an interpretation request to bring
this into scope'. What criteria are involved?


A. Since the Base documents are themselves approved
standards or specifications , the revision process does not have carte
blanche to break the promise that has been made between conforming applications
and implementations, except as noted in the long scope .

There are processes that need to be followed before we have the necessary
authority to make a change to the Base documents that would break
existing applications . These include changes made as a result of
finalized interpretations for the base documents published by IEEE and
ISO/IEC, and finalized corrigenda and resolutions for base documents
published by the Open Group


Q. There appears to be a replacement for this interface, should not
we mark it Legacy?

A. In some cases this is true and a discussion took place in March 1999
to consider which interfaces should be marked Legacy, we believe that
the list is now final. Other interfaces which may have alternatives are
still considered mandatory, deprecating them would break the
contract with the application developer.


Q. I do not like feature XXX and believe it should be removed from
the revision.

A. If feature XXX is from a Base document then its out of scope
to remove it. If not then bear in mind that decisions are made
by concensus and that you may not always be in the majority.

Q. How do I determine what categories to classify an aardvark
comment (objection/comment/editorial)?

A. See http://www.opengroup.org/austin/aardvark/format.html


Pro-forma Responses for the next plenary.

For the next plenary we may introduce a set of pro-forma responses
as a way to speed up processing and also ensure consistency of response.
Attached are  six initial proposed proformas.


R1.Reject: The requirement is from a base document and to change it is out
of scope. Bringing it in scope would require an interpretation,
corrigenda or resolution from the appropriate body.

R2. Reject: this interface is not a candidate for Legacy, the list of
Legacy interfaces was considered in March 1999 and is now final.  It is
widely used in historic practise and deprecating this interface would
break the contract with the application developer.

R3. Reject: we cannot see the problem at the referenced lines, as such
this comment is non-responsive.

R4: Reject: no action is specified in the aardvark comment.

R5: Reject; The review team disagrees with the problem statement because..
 ... {further rationale needed}

R6: Reject: The review team believes that accepting the
proposed change would decrease consensus.