Open Malaysia

4.4 Consistency of documents

In order to achieve the aim of consistency within the complete corpus of documents published by ISO and IEC, the text of every document shall be in accordance with the relevant provisions of existing basic documents published by ISO and IEC. This relates particularly to

a) standardized terminology,
b) principles and methods of terminology,
c) quantities, units and their symbols,
d) abbreviated terms,
e) bibliographic references,
f) technical drawings and diagrams,
g) technical documentation, and
h) graphical symbols

Ecma's did provide a response to this concern in their proposed dispositions on the 14th of January. It was not satisfactory. Their explanation was, to summarise:

1. element names (short or long) has always been an open debate with XML
2. its a personal preference rather than a technical issue
3. terseness is for performance and document size (<c> instead of <cell>)
4. there is already consistency among names, but it could improve during maintenance
5. there should be a "consistent abbreviation principle"
6. recommend DSRL to have XML names dynamically updated to users preferences

Now I don't know where or how to start addressing this response. Is there an 'open debate' on XML names? The goals of XML is to be "humanly readable" and "terseness in XML markup is of minimal importance." Performance? The fact that MSOOXML documents are zipped means that most frequently occurring element names are tokenized to the smallest size for speed. So it becomes a non-issue. Of course we want a consistent abbreviation principle. Thats exactly what this concern requests.

Back to what was discussed at the BRM - logistical issues were raised about this concern:

1. The changes to the spec would be quite extensive, affecting almost ALL the Parts.
2. This would make existing MSOffice 2007 documents incompatible (use DSRL instead!)
3. There will not be enough time within the BRM to come up with the clear instructions for the Editor to follow

I pushed on and said that these quirky names were difficult to understand in English, let alone a non-native English speaker who would have trouble finding the references in a Dictionary.

The Canadian and Australian delegation suggested that the name change could be handled using DSRL which would treat the original spec as one 'language' and write mappers for each element name to proper English. After all, why be so presumptuous and have English as the only language?

The China delegation added that in UOF they tagged each element with a number and used that to rename each element to suit whichever language the user wanted it in. Another country argued that writing these mappings will take time, and that is something we do not have ...

All of these suggestions were valid, and were possible solutions however it did not answer the basic question on why OOXML does not have a proper naming convention, let alone a conscious decision to cater for internationalisation or even naming.

There was consensus then that although this item was simple in concept, was too vast in changes to be handled by the editor, and therefore it's a problem to be addressed during the 'maintenance phase' of this spec.

Malaysia had to concede this issue as to not waste further time (after all, it was the end of the day, and the Swiss were getting twitchy). That is why it has been noted by the convenor that:

MY-16: Names
No consensus emerged on the MY proposal; a reformulation by MY remained possible.

=== Remember Housekeeping notice: My personal views come in thick now ===

Now my personal opinion is that this basic issue should have been addressed when Ecma was preparing Microsoft's original spec which, to me, looks like the C (language) types and structure names from various naming conventions (if any) were 'dumped' into an international standard. I see it as a failing on Ecma's part to apply the minimum requirements of ISO/IEC's Drafting Rules to the specification.

Hey, what is Microsoft paying them for? To produce an international standard, right?

BTW, Ecma held a cocktail event on Thursday evening (28th) and I had an opportunity to chat with Mr Jan van den Beld. He was the head of Ecma and instrumental in seeing OOXML through the process. He re-justified the case for OOXML to us delegates, and yes, he did reiterate his favourite phrase, and Ecma's unofficial motto “Better a good standard today than a perfect one tomorrow”... I guess different people have different definitions of "good"!

He did, with good humour, apologize for being the one responsible for bringing all of us here. That was nice of him ;-)

Maybe I'm too much of an idealist, and he being in the standards business for so long, and having seen so much rubbish (^H^H^H^H vendor specifications) pushed through over the years, has lower expectations for international standards. I dunno. Hey, maybe I AM cynical, too!

... more itty bitty finger food.

So I was disappointed that Malaysia's request for clearer XML names was pushed to a later undefined date to be addressed, but I was also relieved that I didn't have to do the tedious and impossible work of creating editorial instructions to rename all the XML attribute and element names in the 6000 page spec within the following 4 days.

That work, I still believe, should have been Ecma's responsibility 2 years ago, and I hope they address that soon as a work item in SC45, or at least come up with a comprehensive naming convention guide as a first step ...

It also has to be mentioned, that when this item was raised, UK chipped in with one issue of their own which is that the 'e'  element has 18 different definitions (see GB-0537). They wanted these occurrences to be named appropriately.

Ecma's disposition (Response 559) was a null response: they merely agreed with UK, and then listed the 18 e element with its different meanings in a table. Gee, thanks, Ecma! Thats really helpful.

I hope you can now understand the frustration of many National Bodies who found Ecma's responses to be consistently poor and unresponsive. Oh yeah, they are really good with the editorial fixes, but the technical responses unfortunately has a poor track record. Read them for yourselves at www.dis29500.org. It's a great resource.

I have since done more reading up on the ISO/IEC Directives Part 2, and UK's concern is very valid with regards to proper ISO Standards Drafting Rules (Section 4.3 Homogeneity, page 11, my emphasis):

The same term shall be used throughout each document or series of associated documents to designate a given concept. The use of an alternative term (synonym) for a concept already defined shall be avoided. As far as possible, only one meaning shall be attributed to each term chosen.

These requirements are particularly important not only to ensure comprehension of the document, or of the series of associated documents, but also to derive the maximum benefit available through automated text processing techniques and computer-aided translation.
 

So it becomes obvious that UK's concern  GB-0537 is definitely not addressed by Ecma's Response 559. Maybe the Ecma editor needs to brush up on ISO Standards Drafting rules? Or is it another opportunity for DSRL to save the day?

yk.