COR vs. AMD for DR resolution and innovation

[Rex Jaeschke]

Thanks for your feedback Gareth.

Re AMD2, I believe I stated in my cover note when I announced my paper's
availability that the content and plan for processing for AMD2 should stay
as is (as an amendment), as I think it's a special case, not just "an
ordinary DR fix".

I agree, that for more than a few situations, one could argue that piece of
a solution could/should go in a COR and another piece into an AMD. For
example, strictly speaking, an amendment is intended to modify normative
text. So, should an AMD contain new notes or examples or should it change
existing notes or examples? They are NOT normative. In the case of AMD2, I
think it much more important that all the ISO date-related work for
spreadsheet ML go in the same document, and that document seems to me to be
much more like an AMD than a COR.

Regardless of what the Directives say, it's what gets passed the editors in
ITTF that matters. However, the fact that they DON'T reject something is
most likely because they didn't see it during proofing rather than their
having seen it, considered it, and approved it. (I am aware of a case
currently in another standard where they are questioning something in a new
edition that has been in 2 previous editions, but now that they have found
it they are concerned.) Frankly, I'm surprised than neither ITTF nor any NB
commented on the form/content of AMD1. It doesn't look like any other AMD
I've ever seen. Instead, it looks EXACTLY like a COR (which is part of the
argument in my paper).

As I understand, certain parts of the Directives are intentionally left
vague to allow for "special cases". If you asked a lawyer to interpret the
directives on some topic, she might respond, "What do you want them to say?"

Let's discuss this in Tokyo.

Rex
 


> -----Original Message-----
> From: Horton, Gareth [mailto:Gareth_Horton at datawatch.com]
> Sent: Thursday, August 19, 2010 9:48 AM
> To: Rex Jaeschke; e-SC34-WG4 at ecma-international.org
> Subject: RE: Regarding my paper "Rethinking the Use of Amendments to
> Correct ISO/IEC 29500" and this week's telcon agenda
> 
> Hi Rex,
> 
> I was left a little wanting after reading your document, as regards the
> accurate meaning of some of these terms.  I thought I would dig up the
> definitions to help our understanding in the telecom today.
> 
> "A technical corrigendum is issued to correct a *technical defect*. ...
> If the response to a defect report has resulted in correction of a
> *technical defect*, it shall be processed as a technical corrigendum."
> 
> "A published IS may subsequently be modified by the publication of an
> amendment", where, "An amendment is issued to publish a technical
> *addition or change*."
> 
> The directives helpfully define these terms:
> 
> -Defect
> An editorial defect or a technical defect.
> 
> -Editorial defect
> An error which can be assumed to have no consequences in the
> application of the IS, for example a minor printing error.
> 
> -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.
> 
> It seems like editorial defects can only be rolled into corrigenda,
> corrected reprints and revisions.
> 
> One worry I have here is that by this definition, the changes we are
> making in Amd 2 should not be rolled up together.
> 
> Removal of the 1900 date base from transitional would correctly sit in
> an Amendment.
> 
> Redefining the date floor to 0001 from -9999 is difficult to put in the
> right bucket.  It could lead to unsafe application, or it might be said
> that is was more an alteration of an existing technical provision.
> 
> Specification of the allowed forms of date strings in the universe of
> ISO 8601 possibilities is the correction of a defect, so should go in a
> corrigendum.
> 
> Are we, in fact,  contravening JTC1 procedures by not slavishly putting
> one change in an amendment and the other in a corrigendum, even though
> it seems to be common sense to batch the changes this way?
> 
> Gareth
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Rex Jaeschke [mailto:rex at RexJaeschke.com]
> Sent: 17 August 2010 16:44
> To: e-SC34-WG4 at ecma-international.org
> Subject: Regarding my paper "Rethinking the Use of Amendments to
> Correct ISO/IEC 29500" and this week's telcon agenda
> 
> Regarding discussing the following topic on this week's call:
> 
> > Rethinking the Use of Amendments to Correct ISO/IEC 29500 (Rex)
> 
> While I'm not opposed to spending a bit of time on this, given the fact
> that we'll likely have quite a few more NBs represented at the F2F
> meeting in Tokyo than we typically do on a teleconference, I think the
> best time for a detailed discussion of this paper is in Tokyo. There,
> we can go over it on Day 1 and, if necessary, have until Day 3 to make
> a decision.
> 
> Besides, I think that Chris has a lot of DRs he wants to cover this
> week, so we should allocate plenty of time for that.
> 
> Rex
> 
> 
> 
> 
> > -----Original Message-----
> > From: MURATA Makoto (FAMILY Given) [mailto:eb2m-mrt at asahi-net.or.jp]
> > Sent: Tuesday, August 17, 2010 9:26 AM
> > To: e-SC34-WG4 at ecma-international.org
> > Subject: Topics to be discussed in the next teleconf
> >
> > Dear colleagues,
> >
> > Here is my list of topics to be discussed.
> >
> > Updated draft Amendment 2 (Gareth and Chris) Rethinking the Use of
> > Amendments to Correct ISO/IEC 29500 (Rex)
> >
> > DRs
> >
> > DR 10-0010 and DR 10-0011 - General: reference to non-existent Part
> DR
> > 10-0004 - Reference missing from Scope DR 10-0006 - DML: Removal of
> > unused XSD schema reference DR 10-0030 - Schemas: Clearly state the
> > differences between XSD schemas and RNG schemas DR 10-0020 - General:
> > Terminology, 'parent'
> > DR 10-0021 - General: "null" namespace in examples DR 09-0194 - WML:
> > Use of terminology "id" and "unique identifier"
> > DR 10-0008: OPC: Content Types Stream Marku DR 09-0273 - Part 1
> > Normative References Missing DR 09-0196 - General: Conventions for
> > element long names DR 10-0012 - Primer: Defining the Geometry DR
> > 09-0316, 09-317, 09-318: Conformance DR 10-0015 - OPC: Relationship
> > Markup DR 09-0297 - WML: Distribution of elements among Parts DR
> > 09-0320 - OPC: Relationships Markup DR 09-0030 - OPC: Placement of
> > package RelationshipReference elements DR 09-0319 - OPC:
> Relationships
> > Part
> >
> >
> > Font-related DRs (without inputs from Suzuki-san, JP does not have a
> > position yet) DR 09-0045 - WML, Fonts: Character encodings of font
> > names DR 09-0042 - WML, Fonts: notTrueType attribute missing from
> list
> > DR 09-0047 - WML, Fonts: Identifying a face in an embedded font file
> > DR 09-0055 - PML, Presentation: Type of the attribute pitchFamily is
> > too loose DR 09-0061 - Shared MLs, Shared Simple Types: Constrain
> > ST_Panose value set DR 09-0043 - WML, Fonts: notTrueType attribute
> and
> > bitmap fonts DR 09-0041 - WML, Fonts: Font resource search
> >
> >
> > Strings for referencing to OPC parts or ZIP pieces (will be discussed
> > in Tokyo) DR 09-0321 - OPC: Relationships Markup DR 09-0293 - OPC:
> > pack URI scheme DR 09-0292 - OPC: Space characters in part names DR
> > 09-0291 - OPC: Use of term "Unicode string"
> > DR 09-0281 - OPC: Use of the term "part"
> >
> > Regards,
> >
> > SC34/WG4 Convenor
> > MURATA Makoto (FAMILY Given)
> 
> 
>