COR .vs. AM

[Isabelle Valet-Harper (LCA)]

The JTC1 Directives (and the ISO/IEC Directives, same text) say :

technical defect - A technical error or ambiguity in an IS inadvertently introduced either in drafting or in printing which could lead to incorrect or unsafe application of the IS.



technical addition or change - Alteration or addition to previously agreed technical provisions in an existing IS.



As Murata-san, Rex and Francis point out, this is not sufficient to draw a clear line between Amendments and Corrigenda. However there may be some additional guidance in the process itself. The Directives texts,  examined with previous experience in maintaining ISO/IEC standards, show that:

-        A Technical Defect prevents the correct application/implementation of a standard; it will lead to "incorrect or unsafe" implementations, or implementations which will not interoperate. It must be corrected promptly in order not to let those incorrect or unsafe implementations from becoming widespread. To this effect, the process makes clear that :

o   The Project Editor, who has the deepest understanding of the text of the standard, is in charge of making the qualification of a Defect Report into:

1.       Editorial Defect

2.      Technical Defect

3.      No change required

4.      further consideration required

o   Case 2 was designed with the intent of the correction to the defect being approved and published as quickly as possible, so that implementations of the standard get based on corrected text. It implies that the problem is recognized and the correction readily available (either from the defect report submitter or devised by the Editing Group).  To expedite the correction of the defect, the vote is a three-months letter ballot in the SC, initiated by the SC Secretariat upon reception of the proposed Technical Corrigendum from the Project Editor. If the vote is positive, the accompanying  comments, if any,  are dealt with by the Project Editor, again in the interest of a timely correction. Publication is deemed to occur quickly.

o   Case 4 is the situation where there is no urgency in modifying the standard, ie the proposed change or addition does not impact the application of the standard nor the interoperability of implementations. In this case, the item is referred to the WG, for development of a full proposal (with the defect report as a starting point), which  is carried along the normal procedure and results in an Amendment. The procedure for development of an amendment is the same as for the development of a standard, ie  either a new work item (3 months ballot at JTC1 level) or subdivision of an ongoing work item, followed (or concurrent with) the development of a proposal, then approval at ISO/IEC level. Considering the possible groupings, in practice 8-10 months are a minimum.

-        An amendment to a standard is typically a new piece of the standard (which may be prompted by a Defect Report or by a NB or liaison request). The process is designed so that NBs are able to plan the corresponding allocation of resources (it is one of the functions of the NWI or subdivision step) for something which is to be designed, while a Corrigendum  does not need this resource allocation (the change is already available and the vote at SC level, ie among the experts that have likely been associated to the discussion). In terms of volume, there is no precise rule, but a quick look at published standards in the ISO store (http://www.iso.org/iso/iso_catalogue.htm ) show that Technical Corrigenda are often short (one or two pages) while Amendments, much less frequent, correspond to a more substantial piece of standardisation. See for example ISO/IEC 10118-2:2000/Cor 2:2007, 2 pages, vs  ISO/IEC 10118-3:2004/Amd 1:2006 , Dedicated Hash-Function 8 (SHA-224), 16 pages.

-        It must be noted that the two solutions are not automatically exclusive, in particular in difficult cases. For example, a Defect Report may raise a real problem which needs to be fixed quickly, however the fix processed as a Technical Corrigendum may be conservative (merely making sure that implementations are not at risk) while a longer-term,   more comprehensive solution will need to be worked out as an Amendment.



There is a meeting of the JTC1 Directives group next week in Delft (Netherlands). Although it is too late for making a formal contribution to this group, it may be possible for NB delegations, if they find some of the provisions of the Directives unclear,  to discuss the matter informally with other delegations, the JTC1 Chairman or the ITTF representative.  The ITTF representative in these meetings is usually very helpful.



Best regards



Isabelle

-----Original Message-----
From: Francis Cave [mailto:francis at franciscave.com]
Sent: Thursday, February 19, 2009 6:34 AM
To: e-SC34-WG4 at ecma-international.org
Subject: RE: COR .vs. AM



What is the meaning of "ambiguity" in the JTC 1 Directives? The only

possible interpretation is that the text of the standard is ambiguous if it

is possible to implement it in two or more inconsistent ways, based upon

various differing interpretations of the ambiguity. I think one can argue

that any correction of an ambiguity will carry a high risk of breaking

implementations that have interpreted the ambiguity "incorrectly", i.e. to

mean something different from what is finally agreed that it should mean.

The results before and after such a change will in such cases not, in

general, be the same. If one is to accept what ITTF are saying, that would

suggest that no ambiguities can be corrected by a COR but only by an AMD. I

don't believe that their interpretation is reasonable.



Francis Cave







> -----Original Message-----

> From: Rex Jaeschke [mailto:rex at RexJaeschke.com]

> Sent: 19 February 2009 13:42

> To: e-SC34-WG4 at ecma-international.org

> Subject: RE: COR .vs. AM

>

> In December, I raised this question with an editor at ITTF in Geneva.

> Here

> is the relevant extract from his reply:

>

> "From a JTC 1 Directives perspective what is important is the result

> achieved when the standard (ISO 29500) is applied. In other words, if

> someone applies ISO 29500 prior to some change, and another person

> applies

> ISO 29500 after that change, will the result(s) achieved by the two be

> identical?

>

> If the change has no impact on the result achieved when applying ISO

> 29500,

> then a Corrigendum (DR) is sufficient. If the change does, then an

> Amendment

> or revision is required."

>

> I've decided that that explanation really is insufficient. Let me use a

> specific example:

>

> We treated DR 08-0009 (from GB) as a DR and we closed it. It relates to

> the

> WordprocessingML field usage FILESIZE \k and FILESIZE \m.

>

> Consider the case in which an implementer originally interpreted

> kilobytes

> to mean 1024 bytes. If they apply the fix as we agreed, the result of

> this

> field is now in thousands of bytes. Clearly, for many files, the result

> before and after the fix was applied would be different. So, should

> that

> have been processed as an amendment? Actually, our rationale for making

> it a

> DR was that the result of this fix was always the initial intent and

> that's

> was existing implementations did. That is, it was an oversight.

>

> The JTC 1 Directives give the following guidance, but they still appear

> to

> leave room for interpretation:

>

> technical defect - A technical error or ambiguity in an IS

> inadvertently

> introduced either in drafting or in printing which could lead to

> incorrect

> or unsafe application of the IS.

>

> technical addition or change - Alteration or addition to previously

> agreed

> technical provisions in an existing IS.

>

> An amendment is issued to publish a technical addition or change.

>

> Rex

>

>

> > -----Original Message-----

> > From: Shawn Villaron [mailto:shawnv at exchange.microsoft.com]

> > Sent: Wednesday, February 18, 2009 9:36 PM

> > To: MURATA Makoto (FAMILY Given); e-SC34-WG4 at ecma-international.org

> > Subject: RE: COR .vs. AM

> >

> > Murata-san,

> >

> > I think the biggest disconnect here is what constitutes a bug fix

> > versus an extension.  Do you have any thoughts as to guidance we

> could

> > provide regarding the how to differentiate between a bug fix and an

> > extension?

> >

> > Thanks,

> >

> > shawn

> >

> > -----Original Message-----

> > From: MURATA Makoto (FAMILY Given) [mailto:eb2m-mrt at asahi-net.or.jp]

> > Sent: Wednesday, February 18, 2009 6:04 PM

> > To: e-SC34-WG4 at ecma-international.org

> > Subject: COR .vs. AM

> >

> > The convenor wrote:

> >

> > >In the Prague meeting, I would like WG4 to decide (1) whether they

> are

> > >defects and (2) whether we should create amendments for handling

> them.

> > >I would request every member body to think about these questions in

> > >advance.

> >

> > The member body for Japan prefers amendments when proposed solutions

> > are actually extensions rather than bug fixes.

> >

> > Cheers,

> >

> > --

> > MURATA Makoto (FAMILY Given) <EB2M-MRT at asahi-net.or.jp>

> >

>

>

>

>






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20090219/c314f469/attachment.htm>