COR .vs. AM

[Francis Cave]

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