Regarding my paper "Rethinking the Use of Amendments to Correct ISO/IEC 29500" and this week's telcon agenda

[Horton, Gareth]

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)