a 'mooh' point

clearly an IBM drone

ODF 1.2 in ISO (PAS-submission)

The other day a document landed on my "desk" in the Danish Mirror committee to JTC1 SC34. It was the document ”EXPLANATORY REPORT - OASIS Submission of OpenDocument v1.2 to ISO/IEC JTC 1 [JTC1 N12033]”. In other words: ODF TC in OASIS has wished to elevate OASIS ODF 1.2 to an ISO-standard.

OASIS is a so-called "PAS Submitter" to ISO, which enables more or less direct elevation of existing standards to be an ISO-standard, but without any corresponding work on the standard itself in ISO. OASIS ODF TC has used this process for ODF 1.0 back in 2006.

So ODF will not be maintained in ISO - and agreement has been made that work itself developing and improving ODF will be exclusively done in OASIS ODF TC - with subsequent releases to ISO for approval ... what someone might refer to as "rubber-stamping".

For OOXML a different agreement was made during sumission/approval of OOXML - that being that work with OOXML takes place in ISO and this is where the standard is developed and improved. That being said, a substantial amount of work with OOXML takes place in ECMA and a large amount of our work in ISO originates from ECMA's TC45 - the group where OOXML was "born". ODF 1.2 was approved in OASIS in september 2011 (and publicized in early 2012), and now three years later it has landed on our desk in ISO.

I immediately wrote to Danish Standards and told them, that I suggest that Denmark votes "yes". Technically this is not a task for the mirror committee to SC34 since the vote is on JTC1-level, but the more I think about it, the more I doubt that I made the right suggestion to Danish Standards.

Because does it add any value for anybody to - three years after approval in OASIS - ask for an ISO approval? Is there any good reason to spend time on this in OASIS and in ISO? If the argument is that there are some (governmental) institutions that require an ISO-standard level to use it in their organisations/countries - what good is it to them to wait more than three years to submit it to ISO for approval?

Denmark votes "yes" on IS29500 COR1 and FPDAM1

I know it has been a couple of weeks, but I just wanted to share current development with you.

On September 7th (in Danish), the Danish mirror committee to ISO/IEC JTC1 SC34 met at Danish Standards in Charlottenlund. On the agenda was, amongst other things, processing of documents under ballot. The relevant documents to WG4 was these

As appointed expert from Danish Standards in WG4, I have been working hard with the other experts in WG4 on these papers and I have for each meeting in Denmark provided oversights to the mirror committee on the current work. The members of the Danish committee have access to the same set of papers that I have, so we have primarily been discussing the more controversial ones - like usage of ISO-8601 dates in transitional files, reintroducing ST_OnOff in transitional schemas and changing the namespace name for strict files. A couple of times Danish committee members have requested information on more "trivial stuff", and we have then discussed this.

At the meeting of September 7th, I gave a quick sporadic overview of the more tough parts of COR1 and AMD1 and no comments were presented. We talked a bit about general principles of the work in WG4, but that was basically that.

After this, Denmark (Danish Standards) approved the document sets for COR1 and AMD1.

Obviously I think this is great news and the chairman of the Danish committee expressed his appreciation of the work put into creating these files.

Re-introducing on/off-values to ST-OnOff in OOXML Part 4

At this very moment we are discussing re-introducing the values on/off to the simple type ST_OnOff in the transitional part of OOXML.

Background:

Some countries (including Denmark and UK) argued during the DIS29500-process that the enumeration values "on" and "off" of the simple type ST_OnOff were inappropriate since they expanded the W3C Schema data type xsd:boolean. So at the BRM, these values were removed from the simply type ST_OnOff.

Now, that's all fine and dandy - only problem was that it made (according to a Microsoft estimate) 90% of all existing documents (and existing applications) non-conformant. Alex Brown demonstrated this in his article "OOXML and Office 2007 Conformanc: a smoke test". Further, it went directly aganst the scope of IS29500:2008 which was to "represent faithfully the existing corpus of word-processing documents, spreadsheets and presentations that have been produced by Microsoft Office pplications (from Microsoft Office 97 to Microsoft Office 2008, inclusive)".

So we have been disussing this quite a bit - because by re-introducing the values on/off would effectively be reversing a BRM decision ... in other words ... politically, it is a bit of a hot potatoe.

You might argue that this is a prime example of how Microsoft controls SC34/WG4 and how we simply align everything to what Microsoft or Microsoft Office does - but unless you consistantly opt for the sensational news, that position doesn't make very much sense.This has really nothing to do with aligning IS29500 with Microsoft Office; it has to do with aligning IS29500 with its scope.

Now, do note that we in WG4 cannot make decisions to alterating IS29500 - this is the prerogitive of the national bodies in SC34 or JTC1, so all we are doing is suggesting to the NBs that we think it is a good idea to reintroduce the two values.

Smile

WG4-meetings in Copenhagen

So ... everyone on the "who's who" list of OOXML maintenance is in Copenhagen eagerly working our way through a zillion defect reports and proposals for IS29500. The pace varies from hour to hour, but it is almost all of it quite interesting (cough!).

We have quite a busy schedule in front of us for these three days in Copenhagen. The # of DRs have climbed above 250. As you can see on the statistics page of WG4, we have successfully closed about 138 of them (through-out the last few weeks) and we are working our way through the rest.

The topics for this week evolve around mondane tasks as sorting out editorial defect, discussions about technical comments and figuring out what to put in a AMD-bucket and which ones to put in the COR-bucket. It's all about the glamour and fancy life style here.

Smile

We are certainly living in interesting times ... and I am sure we'll get a lot done in these three days.

PS: Ooh ... and we are gonna burn a witch on Tuesday evening.

Extending OOXML

This article will have to topics - one about extending OOXML using the built-in extension mechanisms and one about extending OOXML itself.

Using built-in mechanisms

As I have written about earlier OOXML has a (fun) part containing mechanisms for extending OOXML with vendor/domain-specific extensions. That part is "Part 3 - Markup Compatibility and Extensibility". The part describes different techniques when extending OOXML - most interesting is propably the sections about "Markup Compatibility Attributes and Elements" describing ways to extend OOXML while enabling compatibility to e.g. earlier/current version of the specification.

So if you were a vendor wanting to add something to the spec - but couldn't wait for the slow ISO pace or simply needed the competitive edge of not revealing anything about future software releases to your competitors ... what could you do?

The first thing you should do is to decide if you want your new stuff to eventually make it into the spec. If you don't want that - you're done already.

Assuming you want it into the spec, here are a couple of hints to how you might approach it:

  1. Document your extensions thoroughly
  2. Present these extensions to SC34/WG4 with justification to how and why you want it into the spec
  3. Work with us to polish the nitty-gritty details that you overlooked
  4. Make sure there are no legal nor technical barriers to implementing these new features for your competitors
  5. Wait for the stuff to eventually be included in IS29500

So the real target of this is - if you haven't already guessed it - Microsoft. So to be even more specific, here's a little list of things to do for Microsoft - in case they want to extend IS29500:

You will propably have some additions to IS29500 in your implementation of Office 14. Assuming that you will at some point like these to be added to IS29500, this is what you should do:

  1. Document your extensions thoroughly. Remember, the quality of the documentation will be under the same scrutiny as the text of DIS29500 so please do it right the first time.
  2. Add the documentation of your extensions to your "Implementer's notes" on the DII-website. 
  3. Present these extensions to SC34/WG4 with justification to how and why you want it into the spec.
  4. Work with us to polish the nitty-gritty details that you overlooked.
  5. Include the extensions and the documentation for it in your OSP.
  6. Wait for the stuff to eventually be included in IS29500.

Remember, the minute the first public beta of Office 14 hits the web, the documentation of the extensions as well as inclusion in OSP should be finished. Not a month later, not a week later - on day one!

Extending IS29500 itself

There has been a lot of talk lately to how IS29500 will be extended in the future. Specifically, how - and where - will new additions be included? IS29500 is comprised of two schema sets - a strict set and a transitional set. Currently the strict set is created from the transitional set, so strict is in fact a proper subset of the transitional set.

However - there is no guarentee that this will always be so.

My gut feeling is that transitional should be preserved as the "reflection" of the existing Microsoft Office documents (until March 2008) - in other words in term with the scope of IS29500.  I think that any new stuff should be added to the strict schema set only. The term "transitional" clearly implies this. As I recall the feeling in Geneva at the BRM, the idea behind the transitional set was, that eventually it would no longer be needed and hence removed from the standard - at some point in the future. If we continue to add new features to the transitional set, we will never get to the point where we can honor the sentiment of this particular issue.

...  now at the moment, we haven't decided anything yet ... so right now anything goes.

But what are your thoughts?

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

 

Maintenance of IS26300 in SC34

The streets of Prague are buzzing with rumours coming out of the work in the working groups of SC34 and SC34 itself as SC34 is currently having its plenary meeting in Prague.

It seems that SC34 has done the only clever thing to do - to create an Ad Hoc Group (AHG) to have responsibility of maintaining IS26300. I applaud the decision to do so, and it has in my view been a long time coming.

The details and scope of the group is yet to be seen, but I am glad that SC34 has chosen to create it. There is only one entity responsible for maintaining ISO standards, and that is ISO. Maintenance of IS26300 has falling between two chairs at the moment, where WG1 was initially responsible for it, but it has been preoccupied with other tasks. Also, I think the maintenance agreement of IS26300 has been mentally prohibiting any work being done.

The upside of this is that there is now a group in SC34 responsible for receiving defect reports submitted by NBs. One group is responsible for preparing reports to OASIS and the get the responses back in the ISO system.

This is a clear improvement and it is a sign and a statement that we believe that IS26300 is too important to not have a group responsible for its maintenance in ISO.

Smile

Post WG4-meetings in Okinawa

 

Last week (week 4 of 2009) we had the first face-2-face meeting in SC34/WG4 on the Japanese island of Okinawa. Since there is quite a big overlap between the participants of WG4 and those of WG5, the two groups meet at the same time and place to minimize travel costs and time away.

Quite a lot of people had chosen to take the "small" trip to Okinawa, and at roll-call the first day, a total of 22 people sat around the table in the meeting room. Of these were 6 from ECMA and 14 represented various national bodies (of these were 3 employed by Microsoft)

How's that for full disclosure, eh?

The purpose of the meeting was to get started maintaining OOXML and to discuss what to do in the future. We were also to discuss the already submitted DRs and see what we could do about these.

One of the first things I realized on that morning was, that by participating in standardization in ISO (and from what I hear, also most other standardisation organisations) you need to accept following a certain number of rules. As it turns out, we are in no way free to fix problems in the spec, we are in no way free to make new additions of the spec etc. As it turns out, there are rules constraining all of these activities. So the project editor (Rex Jaeschke) took us on a lengthy trip down "ISO-regulation-lane". The idea was to give us all some knowledge of the rules and terms (as in 'nouns') used in the directives so that we would all be on the same, first page moving forward. The basis for the walk-through was a document prepared by the editor and it is available on WG4's website.

DRs

Quite a lot of DRs were submitted to WG4 before the meeting. I think the total number was about 25-30, and they ranged from fixing spelling errors to clarification of the text and schema changes. The first thing we discussed was how to categorize the DRs. The "buckets" were "defects" and "amendments" and how to distinguish between editorial defects and technical defects. We quickly agreed that focus should initially be to verify and aprove any DRs relating to decisions from Geneva that had not made it into the final text. ECMA also had quite a big batch of DRs submitted before the meetings, but since they were not submitted in time for everyone to look at them, we did not make any decisions about these - ECMA just went through them in detail and we discussed each of them.

Details we discussed were certainly of world-changing importance, such as the difference between the text fragments "nearest thousands of bytes" and "nearest thousand bytes", the allowed content of string-literals and intricate details of the xml:space-attribute in an XML-element based on the XML 1.0 specification. Still, it was quite entertaining and it was delightful to sit back and simply overhear the discussions of people that really know what they were talking about.

Comment collection form

ECMA has set up a comment collection form to submit DRs from interested national bodies. It has already been set to use by the Japanese national body and it seems to serve its purpose just fine. Hopefully it will enable us to improve data qualityof the incoming DRs. We gave feedback to the application to Doug Mahugh from ECMA and hopefully he will see to that the suggestions are implemented (especially mine!)

Smile

We discussed at length the concept of "openness" and how we should apply it to our work, and I will cover my feelings for this in detail in a top-post a bit later.

Last minute impressions

This was my second trip to Japan and I must say that I am getting more and more excited about it for every trip. The culture is fantastic and it is a good challenge to be in a part of the world, where you don't speak the language and is incapable of reading almost any signs. I did get a bit of "Lost in Translation"-feeling on my trip back (+40 hrs!), but it was really a good trip. Two thumbs up for the convener, Murata-san who showed us how a splendid host acts and shows their guests a great time.

All in all I also think we had some productive days on Okinawa. We managed to deal with quite a few DRs and to set up work-processes for the future and I am sure we will benefit in the near future of the work we did. It was also interesting to watch the "arm-wrestling" between the national bodies and ECMA. We were on the same page in most cases, but it was interesting to be part of the discussions where we were not. It will be interesting to see how this will evolve in the future. ISO is a bit different than, say, OASIS because of the involvement of national bodies. Where the basis for most of the groups in OASIS is "vendors", it is quite orthogonal to this in ISO where this concept does not really exist. Some of you may remember Martin Bryan's angry words at the plenary in Kyoto about vendor participation and "positions" vs. "opinions" and I am looking forward to take part in these discussions in WG4 as well as here.

 


Additional resources

Below are a couple of links that might be of interest to you

SC34 WG4 public website

SC34 website

(and for Okinawa-related activities)

Alex Brown's write-up about day 0, 1, 2 and 3-4 of the meetings

Doug Mahugh's summary of what took place

Pictures taken by the secretariat

Picture-stream from Doug Mahugh

Picture stream from Alex Brown

Picture stream from Jesper Lund Stocholm (me!)

Twitter stream from Doug Mahugh

Twitter stream from Alex Brown (notice the l33t-speek Twitter-tag Alex uses!)

Twitter stream from Jesper Lund Stocholm

Bonus for those of you waiting for the credits at the end of the movie:

The day I arrived I was met by Murata-san and Alex Brown in the lobby of the hotel. They were on their way to dinner at a restaurant called "Kalahaai" in the "American Village" of Naha. The dinner took place in a restaurant with live Japanese music from a group called "Tink Tink". Their music was really amazing. The last evening we went there again, and Shawn and I were listening completely baffled to the music and on-stage talks of the performers. It was an amazing experiance to sit in the restaurant not understanding a single word they said - and still not being able to stop listening to them.



(courtesy of Doug Mahugh)

And look at this picture. Thanks to Doug's tele/wide/fish-eye-whatever-lense on his camera, I look like an absolutely mad-/maniac man! No girls were hurt during this, I should point out.


(courtesy of Doug Mahugh)

Smile

JTC1/SC34 WG4 appointed Danish expert

On Friday, October 24th the Danish mirror-committee to JTC1/SC34 had its bi-monthly meeting. On the agenda was, amongst other things, assignment of participants to the newly created working groups in JTC1/SC34, WG4 and WG5.

For those of you not familiar with the establishment of these two groups, WG4 will deal with maintenance and development of OOXML. WG5 will work to "Develop principles of, and guidelines for, interoperability among documents represented using heterogeneous ISO/IEC document file formats." So the latter WG is not really about translating between document formats such as ODF and OOXML. No, it is about creating some guidelines that all (future or present) document formats could use as inspiration when designing the formats to be "interoperable".

I think the prospects of this could be really, really good and I hope as many stakeholders as possible chooses to join the work. It would be great to have som kind of guidelines for interoperability comparable to the Accessibility-guidelines from W3C (those that was added to OOXML during the BRM in Geneva).

We did not get any confirmed pledges to participate from the members of the Danish committee, but I was very pleased to hear that both ORACLE Denmark as well as the Technical University of Denmark would investigate if they could join the working group.

More interesting to me was assignment of participants for Working Group 4 to develop and maintain OOXML. Not surprisingly (since most of the participants of the committee are much more "anti-OOXML" than "pro-ODF" this point of the agenda received far less attention. We have in CIBER Denmark discussed for quite some time if we should join the working group, and we have reached the conclusion that we would. We do this of the following reasons:

  1. We believe that we would be able to deliver some technical skills that would be valuable to the work around OOXML
  2. We believe that it is important that development and maintenance of OOXML is not done exclusively by ECMA under the "ISO brand" and
  3. we believe that it is important to create a Danish "foot-print" on the development of the document format
So when the committee was asked if anyone would join, CIBER stepped up to the plate. I am happy to say that both the potential commitment of ORACLE Denmark and Technical University of Denmark and the confirmed commitment from CIBER received unanimous support from the other committee members.

So now what?

well, the first draft of the agenda for the meeting in Okinawa has been posted on the SC34-website. At present the agenda is this:

Draft agenda

  1. Opening - 2009-01-28 10:00
  2. Roll call of Delegates
  3. Adoption of the Agenda
  4. Defect Reports
  5. Any other business
  6. Closing

I think we will also talk about what to actually do in the foreseeable future both with respect to handling of defect reports and future maintenance. One of the things I will not accept (and I hope nor will the other appointed experts) is that the working group will primarily focus our time on defect handling - all while ECMA works on new stuff for OOXML and eventually dumping this on our table. So we will need to establish some sort of agreement around this.

Also we will need to talk about future places to meet. Next meeting will likely be held in Pragh, and I would like to some how make sure that future meetings are held in cities near major airport hubs around the world. It will take me about 24 hours to travel from Copenhagen to Okinawa, and that travel period would be cut in two, if the meeting was held in e.g. Tokyo or Kyoto. This is not a criticisme of the Japaneese decision to have the meeting in Okinawa, but I believe we would indirectly encourage more participation if the required travelling was not so extensive.

Oh ... and did anyone notice that I was only mentioned in the "Small news"-section of Alex Brown's recent post "More Standards news"? This really helps keeping both feet solidly on the ground and not thinking too much of myself.

Wink

EEE - the SC34-way

In my recent post about the outcome of the AHG1-meeting in London, IBM's Rob Weir pointed out, that

What everyone is missing is the fact that Microsoft is not obligated to participate in SC34/WG4 maintenance, or to do maintenance exclusively in SC34/WG4. Ecma is fully capable of submitting any future version of OOXML under Fast Track rules directly to JTC1 (not SC34) for another 6-month ballot.

Well, as I have said repetedly before, when Rob is right, he is right, and this is no exception. As JTC1 Class A Liaison (there are actually only three of those, the other being ITU and the European Union, if I remember correctly), they can do pretty much what they want. So if we wanted to ensure maintance of OOXML would take place completely in SC34, we couldn't rely on JTC1 directives for help. We had to do something else.

One way would be to strong-arm ECMA into signing a binding, legal letter in which they committed to exclusive maintenance of OOXML in SC34. I you ask me, I don't think that is a good idea. I think most of us will agree, that this process has seen too many lawyers already.

Another way would be to indirectly make sure that ECMA does all their activities within the SC34-sphere. Like all organisations, people with the right skills are a constrained resource and it is in no way different for ECMA. As Rob pointed out, there is only limited time available for everyone, and we all need to prioritize our resources. So even though we did not discuss this particular angle with respect to ensuring maintenance in SC34, this was in effect what was the result.

SC34 needs to appoint resources to two areas when setting up WG4:

  1. The editor of the project
  2. Who should run the secretariat for the working group


ECMA volunteered to manage both areas, and we discussed quite a bit about that being a good idea or not. Come to think of it, I think it is.

ECMA (here Rex Jaeschke) has been the editor throughout the process - first in ECMA itself and next in ISO. It is clear that he has the right skill-set to follow the process and he has a clear interest in a fast-paced process. ECMA also volunteered to run the secretariat for the WG. As I wrote in my previous post, the work-load of the WG will be quite big, and a secretariat is really needed to keep track with everyone, to coordinate meetings and to create meeting reports, agendas etc.

So what we essentially did was a "Tripple-E" on ECMA. We have embraced ECMA and their OOXML-resources and we have sure, that given the amount of resources they are to put into SC34/WG4, they are not likely to have their own work run in parallel in ECMA. Now, at some point WG4 will be presented suggestions for additions to the specification. These could be from ECMA, but they could be from just about any member of SC34 - including countries opposing OOXML or competing companies represented in their favorite country. This is really the "ISO-model" at work.

So, you might say, this is just a load of good intentions and wishes for the best possible outcome ... and this is perfectly correct. Sadly though, these were our only options given the JTC1 directives. You might also say that it is highly likely that ECMA will be the only entity that will show up with additions to the specification. I have absolutely no idea of the propabilities for this to happen, but I think it would be very sad. We need other stakeholders and participants in the work with OOXML than ECMA and the national bodies' standards people and I think it would be unfortunate if the only stakeholder in WG4 with real, hands-on experience with creation of Office applications was ECMA. As Rick pointed out the major participants in ODF TC all develop applications based on the same code base and rumour even has it that development of additions to ODF is largely driven by Sun's development of OpenOffice.org in a "we need this element for our implementation - please put it in the specification"-kind-of-way. I have no idea if it is only a theoretical issue or if it is a concrete problem, but I would imagine that a document format to be used by a variety of implementations would benefit from different implementations being present at the development table. This is indeed also true for OOXML. We need the competitors of Microsoft at the table as well.

(ECMA TC-45 already consists of major office suite developers (Apple, Microsoft, Novell etc), so you already have the diversity of vendors present, but I have collectively referred to them as "ECMA". I would still, however, prefer to have participants present not associated with ECMA)

Side-note:

Luckily, you should brace yourselves that even in the event that everything mentioned above falls apart and ECMA litteraly goes their own way, the net effect will "just" be that maintenance of OOXML will be as with ODF where OASIS ODF TC works on maintenance completely seperate from JTC1/SC34.