a 'mooh' point

clearly an IBM drone

The actual work we did in Prague

I thought I’d try to outline a bit what we actually did and what constituted our work in Prague.

The agenda framing our work throughout these three days was this:

  1. Opening 2009-03-24 09:00
  2. Roll call of delegates
  3. Adoption of the agenda
  4. Schedule for publication of reprints or Technical Corrigenda
  5. Defect reports
  6. Future meeting (face-to-face and teleconferences)
  7. Any other business
  8. Extension proposals from member bodies and liaisons
  9. Conformance testing
  10. Closing

The vast majority of our work was in item number 5 on the agenda and each and every single minute was used discussing the defect reports – including in lavatories, on our way to work, on our way back from work, during lunch, dinner, breaks and drinks … in short – we discussed DRs 24/7. This was as it was supposed to be – this was really the reason for all of us being in Prague.

The initial list of DRs we discussed was this (just to give you an idea of what we talked about):

08-0001 — DML, FRAMEWORK: REMOVAL OF ST_PERCENTAGEDECIMAL FROM THE STRICT SCHEMA
08-0002 — PRIMER: FORMAT OF ST_POSITIVEPERCENTAGE VALUES IN STRICT MODE EXAMPLES
08-0003 — DML, MAIN: FORMAT OF ST_POSITIVEPERCENTAGE VALUES IN STRICT MODE EXAMPLES
08-0004 — DML, DIAGRAMS: TYPE FOR PRSET ATTRIBUTES
08-0005 — PML, ANIMATION: DESCRIPTION OF HSL ATTRIBUTES LIGHTNESS AND SATURATION
08-0006 — PML, ANIMATION: DESCRIPTION OF RGB ATTRIBUTES BLUE, GREEN AND RED
08-0007 — DML, MAIN: FORMAT OF ST_TEXTBULLETSIZEPERCENT PERCENTAGE
08-0008 — DML, MAIN: FORMAT OF BUSZPCT PERCENTAGE VALUES IN STRICT MODE EXAMPLE
08-0009 — WML, FIELDS: INCONSISTENCY BETWEEN FILESIZE BEHAVIOUR AND EXAMPLE
08-0010 — WML: USE OF TRANSITIONAL ATTRIBUTE IN TBLLOOK STRICT MODE EXAMPLES
08-0011 — WML: USE OF TRANSITIONAL ATTRIBUTE IN CNFSTYLE STRICT MODE EXAMPLE
08-0012 — SCHEMAS: SUPPOSEDLY INCORRECT SCHEMA NAMESPACE NAMES

I think it’d be fair to say that we have come a long way since the time we were discussing if it was possible to use XSLT to simulate bit-switching or if an OOXML-file was “proper XML”.

For each of the DRs we covered we discussed if the DR was a technical defect or an editorial defect, what the possible implications of the DR would be to existing documents and existing implementations and if the DR belonged in a corrigendum (COR) or if it was an amendment (AMD). It was quite tedious work, but we managed to cover quite a lot of ground in the three days.

Corrigendum or amendment?

One of the first things to accept when working in ISO is that there are quite the number of rules to comply to. As it turns out, it is not our prerogative to decide if a DR goes into “the COR bucket” or if it goes into “the AMD bucket” – there are rules for this. The ISO directives section 2.10.2 state that

A technical corrigendum is issued to correct [...] a technical error or ambiguity in an International Standard, a Technical Specification, a Publicly Available Specification or a Technical Report, inadvertently introduced either in drafting or in printing and which could lead to incorrect or unsafe application of the publication

If the above is not the case, the modification should be handled as an amendment.

Still, there are quite a lot of DRs that fall into the more gray outskirts of this definition. So to facilitate our work we made some guiding principles, and these principles were discussed at the SC34 plenary in Prague:

[…] in the interest of resolving minor omissions in a timely fashion, WG4 plans to apply the following criteria for deciding that the unintentional omission or restriction of a feature may be resolved by Corrigendum rather than by Amendment. All of the following criteria should be met for the defect to be resolved by Corrigendum:

  1. WG 4 agrees that the defect is an unintentional drafting error.
  2. WG 4 agrees that the defect can be resolved without the theoretical possibility of breaking existing conformant implementations of the standard.
  3. WG 4 agrees that the defect can be resolved without introducing any significant new feature.

Unless all the above criteria are met, the defect should be resolved by Amendment.

Of course we will still have to do an assessment for each and every DR we look at, but it is our view that these principles will help us quite a bit along the way and to have a more expeditious workflow. Notice also the wording “WG4 agrees”. A very small number of DRs falls clearly into the COR- or AMD-bucket, so it is not possible to regard these principles as a mere algorithm with a deterministic result. The principles requires WG4 to agree to the categorization of DRs so we’ll actually have to sit down and talk everything through.

On the first day (or was it second?) we also touched briefly upon the subject of modifying decisions made at the BRM. The delegates at the BRM were nothing but normal people, and due to the short timeframe of the meeting, errors likely occurred. At some point or another, someone will discover we made a mistake and put a DR on our table. At this point we will have to figure out if we think the decisions made at the BRM are now cast in stone or if they should be treated by the same criteria as the other DR we receive. As I said, we just touched upon the subject and didn’t reach any conclusions to this. If you have any thoughts regarding this, please let me (and us) know. My personal opinion on this subject is, that we in WG4, at this point in time, should be extremely careful when thinking about reversing decisions made at the BRM.

And finally, I thought I’d give you some pointers about what is in the pipeline of blog entries (I don’t have a sophisticated system as some people, so I’d just give you a small list of topics at the top of my mind these days:

  • Markup Compatibility and Extensibility
  • Conformance class whatnots
  • Namespace changes and the considerations about doing it or not
  • Why should we care about XPS?
  • Why I like the ISO model
  • Maintenance of IS26300 in ISO

 

Comments (2) -

I'd really like to see you write about Markup Compatibility. I don't know about everyone else, but its an issue I'd like to hear your thought leadership on.

I suspect the reason for distinguishing is that a Corrigendum is much easier to approve, and very often the need  is to get it out quickly.

On the other hand - ammendments adds new features and must be approved as standards

And I would like to add that a standard very often gets several ammendments and corrigendi during its lifetime.

/esni

Comments are closed