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

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

Matthew et al

See comments below.

regards
Julian

On 2003-12-30 at 13:48, you wrote:

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

JPF: I will check through my archives of ISO materials and send 
copies of any relevant documents/definitions (although probably not 
until the end of this week).  If ISO does not provide a definition of 
"conformance", then the definitions(s) provided in the 10th edition 
of the Concise Oxford English Dictionary apply.

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

JPF> I suspect that we may be dealing with different levels of 
metadiscourse here ... I'll go back and read the relevant parts of 
your document together with Frank's comments.

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


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