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

["West, Matthew R SITI-ITPSIE" <matthew.west@shell.com>]

Dear Julian,

Thanks for these comments.

Just a couple of practical questions.


Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom

Tel: +44 20 7934 4490 Mobile: +44 7796 336538
Email: matthew.west@shell.com
Internet: http://www.shell.com
http://www.matthew-west.org.uk


<snip>
> > 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.

MW: I would happily adopt these definitions if I could find them, 
or if someone gave them to me. I already asked Frank for them, but I
have only had silence. I can find no Definitions section in the
ISO/IEC directives, and when I did a search on "conformance" I found
it was used but not defined anywhere.
> 
> > 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.

MW: I'm not quite sure what I am supposed to do here. The word 
"principles" is used twice, once in the section title "Fundamental
Principles" and once in the text "... principles of quality management".

MW: It is quite common for ISO standards to have a "Fundamental
Principles" section that makes various statements on which the
standard is founded. I am not using "principles" rather than "statements"
I am making "statements" of "principles".

<snip>

> > 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).

MW: I have laready changed this to allow any clause to be either
informative or normative, although the IEEE Style Guide says that 
the intention of IEEE is to move towards the same documentation
approach as ISO. However, this woudl not be a big deal if you moved
from an IEEE standard to an ISO one.
> 
> > 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
> 
> 
>