Defect report from : Mark Ziegast , SHware Systems
(Please direct followup comments direct to yyyyyyyyyyyyyy@xxxxxxxxxxxxx)
@ page 1 line 1 section 1, also XSH, XCU objection {020617-01}
Problem:
Defect code : 1. Error
XBD ERN 38 raised a problem of inconsistency of usage of margin codes
to map appropriately the scope of an Option Identifier in unistd.h and
other Option Labels in other parts of XBD with the appropriate content
in other portions of the standard, as exemplified in the Conformance
Requirements Section. This aardvark is to change the classification to
objection from editorial, rather than just continue ERN 38. My research
indicates the Action proposed in ERN 38, suitably formatted and cross-
referenced, is required for the standard to satisfy an overriding standard,
the ISO Directives, and a few guidelines. I feel the use of a TC item that
addresses this mandate can be held as the standard being fully compliant,
at least in spirit, rather than forcing a mandatory thumbs down vote so the
work needed for it to qualify both in spirit and to the letter may be
completed, with the attendant time delay. To what extent this problem may
deviate from IEEE standards I have not investigated. For some reason, my
web client setup and their server appear to be incompatible, so I cannot
access any content that is nominally no-fee material. As I am not an IEEE
member, the members only areas are certainly not accessible to me, as are
OpenGroups and ISOs member areas.
To wit, The ISO Directives, Part 2, currently Edition 4, specifies the
format a draft standard shall have for it to be acceptable as a valid
submission for voting approval. Given the complexities inherent in the
merging of the prior standards, each of which was satisfactory in themselves
to their sponsoring organizations, I can only see that the combination as
currently formatted does not match what is permissable leeway to a standard
of this complexity by the ISO; and somewhere along the way sight was lost
that it was divergent. That the Directives are not listed as either an
informative or normative reference leads me to believe they were presumed
to have been satisfied by use of the ISO templates, not verified as such in
the planning phases of the document - a case of the forest being lost for
the trees, as it were. The templates are listed as a starting point for
compliance, however, not a guarantor. The standard is complex enough, with
multiple layers of Optional Requirements, that it requires and devotes an
entire Section to the Requirements Clause, which is nominally an Optional
Element. This Clause is formatted in a manner the Directives deems shall NOT
be acceptable, and is lacking required content as well! The entire document
is formatted incorrectly also, as it does not support the mandates placed
on this Clause to enable standard cross-referencing to be used.
Rationale:
From ISO Directives, Part 2:
--- begin quote ---
6.3.3 Requirements
This element is optional. If present, it shall contain the following:
a) all characteristics relevant to the aspects of the products, processes
or services covered by the document, either explicitly or by reference;
b) the required limiting values of quantifiable characteristics;
c) for each requirement, either a reference to the test method for
determining or verifying the values of the characteristic, or the test
method itself (see 6.3.5).
A clear distinction shall be made between requirements, statements and
recommendations.
--- snip ---
6.6.7 References
6.6.7.1 General
As a general rule, references to particular pieces of text shall be used
instead of repetition of the original source material, since such repetition
involves the risk of error or inconsistency and increases the length of the
document. However, if it is considered necessary to repeat such material,
its source shall be identified precisely.
References shall be made in the forms indicated in 6.6.7.2 to 6.6.7.5 and
shall not be made to page numbers.
--- end quote ---
The main area where the Conformance Requirements Section does not match
these Requirements is that the notion "Everything not an Optional Requirement
is a base Requirement" is an Inference, not a Reference or Explicit List
of the Characteristics of the base Requirements, that forces a reader to
disambiguate recommendations and statements from Requirements. The use of
option identifiers and respective margin codes as a means of specifying
References to Optional Requirements is inherently contrary to the formats
6.6.7 dictates SHALL be used. The margin codes, structurally, are only an
Informative Element, not a Normative Element usable as a Reference. They
would be valid Abbreviated References if there were some item specifying
all Sections where the Optional Requirement each denotes is used. The
corollary is everywhere a Margin Code currently appears requires a section
number suitable for cross Part references. For those places where codes
appear in the middle of sentences, those sentences require rewording.
The only real option is to get a formal dispensation of the Directives
from the ISO Secretariat, and incorporate this as part of the Foreward
to XBD. In the interests of allowing other standards to easily reference
this one, however, if it were up to me I would disapprove granting such
a dispensation. I would allow, as stated above, that a commitment to
incorporate the fix into TC1 by the sponsoring organizations may let a
thumbs up vote based on the other merits of the content be granted.
This is a case where context matters almost as much as content, though,
because it must be considered within a larger context than just the
confines of the document. That it defers much of its base Requirements
to ISO 9899:2001 is the most prominent example; that XCURSES defers to
it wholly as it's primary normative reference the other.
Commentary:
Another matter brought out by the discussion on XBD ERN 38 I feel
should be mentioned is Part 1 of the ISO Directives specifies that
resources needed to accomplish the work of formatting and drafting
a standard shall be allocated or acquireable by the sponsoring
organizations prior to commencement of the work, and it is up to them
to insure that work is done in a timely fashion. It is not the
responsibility of the target audience to allocate their own resources
to do this work on their behalf. Thus, the argument resources aren't
available to perform this work is disallowed, despite the scope of the
change and attendant increase in size of TC1. In my case, even if I
wanted to allocate the full resources needed to do this aspect of the
work, I don't have or can acquire all of them to satisfy the Directives,
Guidelines and Standards of ISO, IEEE, and OG. I can provide ad hoc
recommendations, nominally, as I have been doing and which this aardvark
is also, based on my prior experience in drafting smaller standards
that conformed to other Directives, but it's not incumbent or even
legitimate for me to do more.
Action:
I defer to the ISO Guidelines that aren't available gratis as to
how these recommendations should be finalized by the editorial team.
Without these, anything definitive I might propose would be very
lucky to not be controversial in some aspect. While the format
outlined in ERN 38 for which tables should be included was off the
cuff on my part, and based more on the standard of prior industry
practice, it does match fairly well with what the Directives and ISO
Guide 2 mandate as Titles for the types of Requirement as it pertains
to the standard. The format of each table can follow that of APIs.html,
with an additional "column" for relevant section numbers. At the least,
I feel section numbers for each header, interface and utility shall
be assigned. I'm ambiguous on whether subsections must be assigned
numbers also, but they should be to better pinpoint references. I feel
it would be useful if additional subsections, like environment variable
and structure usages, were collated by requirement type also. The
margin codes abbreviations reference should include cross-references
to sections also, and may take the place of the additional "column",
perhaps. Codes for mandated, normative, and previously optional
requirements should be created and applied, to satisfy consistency of
usage requirements, and satisfy better the split of requirement text
from recommendations.
|