Re: P&P: RE: Fw: SUO: Motion to Adopt Standard Upper Ont

["Julian Fowler" <jfowler@pdtsolutions.co.uk>]

Frank, Matthew, et al

On 2003-12-20 at 16:11, you wrote:

> 
> Matthew-
> 
> I am strongly opposed to your procedures document because it
> re-invents terminology and parts of the standards process -- and it
> re-invents them imprecisely, which is of little good to us.  I believe
> you are a participant of ISO TC184, yet I would have expected that
> your documents regarding the standards process would have used ISO
> "standards terminology" (e.g., ISO/IEC Directives, ISO/IEC Guide 2,
> etc.) rather than using the Oxford English Dictionary (<-- good for
> lay people, poor for technical definitions).  

ISO/IEC Directives specifically reference the Concise Oxford English 
Dictionary for two purposes: firstly as the required reference for 
spelling, secondly as a baseline for the definitions of common terms.

Within ISO TC184/SC4, the ISO/IEC Directives etc. were found to be 
insufficiently precise to meet the committee's work.  SC4 itself 
therefore developed and continues to maintain three documents: the 
SC4 Handbook (which interprets and extends ISO/IEC Directives Part 1 
with respect to policies, procedures, and processes for standards 
development); the SC4 Quality Manual (which sets out the processes 
and criteria applied to ensure a high level of quality in the 
committee's standards), and the SC4 Supplementary Directives (which 
interpret and extend ISO/IEC Directives Part 2 with respect to the 
structure, content, and presentation of SC4 standards).  I'm not 
suggesting, by the way, that SUO needs to parallel any more than a 
fraction of this material (at its most active, ISO TC184/SC4's work 
involved more than 500 experts developing up to 100 separate 
standards documents)!

The development guidelines document that Matthew has drafted and 
proposed is similar to the first of these (albeit for an activity 
under a different standardization umbrella and of considerably 
smaller scale and complexity).

> For example, the terms
> "conformance", "defect", "definition", "example", "formal issue",
> "informative", "normative", "principle", and "term" are all defined in
> ISO sources or have their ISO equivalents (e.g., "formal issue" would
> be a line-item on the ISO comment form, which is part of comment
> resolution, which may be part of ballot resolution).

Most or all of these are defined in ISO/IEC Directives; I suggest 
that the definitions given there should be used here if possible.  
These definitions should be restated verbatim in the SUO document 
with a citation of their source.

> Regarding the notion of "principles", standards have a notion of
> "provisions" (requirement, recommendation, statement, instruction). 
> We should simply use what already exists.  The wording in Clause 4
> appears to be either recommendations or statments -- my guess is that
> you intend for "recommendations" since there are no "requirements" in
> Clause 4.

I agree with this suggestion, on the basis that parallel language 
forms with other standards and standardization groups aids 
understanding.

> Regarding Clause 5, the work programme for this working group is
> clearly defined: currently, we have 1 PAR (project) outstanding <--
> that is our work programme.  If we want more projects, we need to
> request them (I haven't seen any requests for additional projects).
> 
> Regarding subclause 5.2 and 5.3, the so-called "deliverable" is what
> IEEE calls a "standard", "recommendation", or "guideline" <-- a formal
> result of a unit of the work programme (project == unit of work
> programme).
> 
> So I suggest we postpone discussion of your procedures document until
> you can tell us how we make progress on the work we a required to do.
> 
> Regarding Clause 6, for international and national standards, your
> concerns about "an untrue statement, an unclear, ambiguous or
> misleading statement, something missing that is necessary" aren't the
> proper criteria for issues.  The criteria for issues is: text that
> causes the lack of consensus (regardless of reason).  As an example,
> certain standards wording is purposely ambiguous (e.g., it permits a
> range of implementations) and other kinds of standards wording
> purposely have features where "something missing that is necessary"
> (<- this is known as "implementation-defined").  So I believe this
> criteria is incorrect.

My experience here is that the criteria that Matthew has identified 
are exceedingly useful (a) in guiding reviewers with respect to the 
kind of issues that are to developed, and (b) helps developers to 
understand the kinds of change that are likely to address reviewers' 
concerns.  I agree that these are not absolute criteria; however, 
this approach is infinitely better than having volumes of issues that 
are little more than "I don't like this" or "I wouldn't do this that 
way" or ...

Having been involved in processing of numerous ISO ballot responses, 
some with in excess of 1000 issues, I strongly recommend that a high 
level classification of issues is retained for the use of this group.

> Regarding Annex 3, the split between "normative" and "informative" is
> inaccurate -- whole clauses and subclauses can be informative.

The approach that Matthew describes is that of ISO, in which the 
informative content of a standard is limited to the preamble 
(Foreword/Introduction), Informative Annexes, and the Notes/Examples 
found in the normative clauses/subclauses of the standard.  There's 
no specific reason to adopt this hear (unless doing so otherwise 
clarifies ambiguity in the structure/content of IEEE documents).

> If your notion of "deliverable" means "project" in the IEEE sense,
> then your process has re-invented the IEEE process.  If your notion of
> "deliverable" does not mean "project" in the IEEE sense, then it is
> unclear how you "devlierable" actually relates to the P1600.01 project
> this is established -- i.e., this is all nice discussion, but the
> purpose of IEEE Working Groups is to produce standards, not just
> facilatate discussion.
> 
> As you can see, I believe there are major problems with your document
> -- and I find the document unnecessary because we already have a
> document for the IEEE standards development process.

Whilst its clear that the procedures/guidelines specific to the SUO 
activity must be 100% consistent with the IEEE process, I believe 
that there is considerable utility in having a document (preferably a 
short, simple one) that both states the requirements that a community 
of standards developers have to meet, and provides pointers to the 
detailed sources of those requirements.  My experience in ISO 
TC184/SC4 and other standards groups suggests an overwhelming desire 
on the part of standards developers *not* to read any document that 
does not appear to be directly relevant to their activities (and 
documents such as the ISO/IEC Directives definitely fall into that 
category).

Julian


-- 
Julian Fowler, PDT Solutions
Telephone: +44 15242 63389 Mobile: +44 7764 770511
Fax: +44 870 052 3414 Email: jfowler@pdtsolutions.co.uk
http://www.pdtsolutions.co.uk