a 'mooh' point

clearly an IBM drone

Microsoft-stacking in WG4

Traditionally, for every meeting we have in WG4, some conspiracy-theory is born on how much money the delegates received from Microsoft, how many sports-cars we each got from Microsoft or how we each had a Microsoft employee sitting on our laps dictating what we should say.

So, I thought I'd beat the usual nut jobs to it and present the attendance list myself. The minutes from the meeting will be available soon, but who wants to wait for exiting news like this?

The attendance list was this:

Name Affiliation
Employer/sponsor
Pia Lange
Host Dansk Standard
Makato Murata
WG4 Convener
International University of Japan
Sam Oh
SC34 Chair
Sungkyunkwan University
Keld Simonsen
NO HoD DKUUG?
Dave Welsh
US HoD
Microsoft
Mario Wendt
DE HoD
Microsoft
Klaus-Peter Eckert
DE Fraunhofer Fokus
Jesper Lund Stocholm
DK HoD
CIBER
Rex Jaeschke ECMA HoD, project editor Consultant
Doug Mahugh
ECMA
Microsoft
Shawn Villaron
ECMA
Microsoft
Kimmo Bergious
FI HoD
Microsoft
Alex Brown
GB HoD
Griffin Brown Digital Publishing Ltd.
Gareth Horton
GB
Datawatch
Jaeho Lee
KR HoD
University of Seoul
Jung-Jin Yang
KR
The Catholic Univeristy of Korea

So out of a total of 1416 people attending ... 56 people were in some way affiliated with Microsoft and/or ECMA. What the hell, throw the Microsoft shill Alex Brown into the pot as well - that'll make it a total of 67 people.

I don't know what to say ... I'm shocked.

Update: I have been notified that I missed two persons on the list, Dave Welch and Keld Simonsen. List and numbers have been updated accordingly. Smile

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.

Lo(o)sing data the silent way - all the rest of it

Ok - this post is going to be soooo different than what I had envisioned. I had prepared documents for "object embedding" and "document protection" but when I started testing them, I soon realized that only Microsoft Office 2007 implemented these features - at least amongst the applications I had access to. These were:

Microsoft Office 2007 SP2

OpenOffice.org 3.0.1 (Windows)

OpenOffice.org 3.0.1 (Mac OS X)

NeoOffice (Mac)

iWorks 09 (Mac)

The reason?

  • OOo3 doesn't fully support object embeddin
  • OOo3 doesnt support document protection
  • iWorks doesn't support object embedding at all
  • iWorks doesn't support document protection

So I'll just give you one example of what will happen when strict documents come into play - when applied to document protection.

Document protection is the feature that allows an application to have a user enter a password and unless another user knows of this password, he or she cannot open the document in, say, "write-mode". There is no real security to it, though, it is simply a hashed password that gets stored in the document.

This data is stored in the "settings.xml"-file in the document, and this was rather drastically changed during the ISO-process.

If you use Microsoft Office 2007 to protect your document, it will result in an XML-fragment like this:

[code:xml]<w:documentProtection
  w:edit="readOnly"
  w:enforcement="1"
  w:cryptProviderType="rsaFull"
  w:cryptAlgorithmClass="hash"
  w:cryptAlgorithmType="typeAny"
  w:cryptAlgorithmSid="4"
  w:cryptSpinCount="100000"
  w:hash="XbDzpXCrrK+zmGGBk++64G99GG4="
  w:salt="aX4wmQT0Kx6oAqUmX6RwGQ=="/>[/code]

You will have to look into the specification to figure out what it says, but basically it tells you that it created the hash using the weak algorithm specified in ECMA-376.

But as I said, this was changed during the BRM. Quite a few of the attributes are now gone for the strict schemas, and my take on a transformation of the above to the new, strict edition is this:

[code:xml]<w:documentProtection
  w:edit="readOnly"
  w:enforcement="1"
  w:algorithmName="typeAny"
  w:spinCount="100000"
  w:hashValue="XbDzpXCrrK+zmGGBk++64G99GG4="
  w:saltValue="aX4wmQT0Kx6oAqUmX6RwGQ=="/>[/code] 

'Only thing I am a bit unsure about is the value for the attribute "algorithmName", but I guess it would be "typeAny". The result? Microsoft Office 2007 detects that the document has been protected, but it cannot remove the protection again - presumably due to the new attributes added to the schemas. I thought about creating new values using e.g. SHA-256 as specified in the spec, but the chances that Microsoft Office 2007 would detect this in unknown attribute values are almost nothing, so I didn't bother doing this. Feel to play around with it yourself.

The Chase

We need a namespace change for the strict schemas - and am thinking about ALL of the strict schemas including OPC. If we don't do it this way, my estimate is that we will lose all kinds of data - and the existing applications will not (as they behave currently) inform their users of it. Making existing applications break is a tough call, but I value data/information integrity more than vendors needing to update a bit of their code.

And as for the conformance attribute? Well, the suggestion as it is currently is to enlarge the range of allowed values of this attribute. Somehow I think it makes sense to enlarge the range as well.I think it would make sense to have the values one of

  • strict
  • transitional
  • ecma-376

or something similar. Then when we make a new revision at some point in the future, we can add version numbers to them at that time. Changing the namespaces will also make it possible to use MCE to take advantage of new features of IS29500 while maintaining compatibility with existing applications supporting only ECMA-376 1ed. (more about this later)

And what should the schemas be named?

Well, they are currently like "http://schemas.openxmlformats.org/wordprocessingml/2006/main" . So an obvious choice would be "http://schemas.openxmlformats.org/wordprocessingml/JLUNDSTOCHOLM/main"

Smile

... or maybe simply "http://schemas.openxmlformats.org/wordprocessingml/main" would be better? Of course it introduces easy causes for errors for developers, so maybe "http://schemas.openxmlformats.org/wordprocessingml/iso/main" would be even better?

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

 

WG4 meetings in Prague

Wow – this has been a tough week. I arrived at the hotel here in Prague (I am currently waiting in Prague Airport for my flight back to Copenhagen) at around 21:00. I met Doug in Copenhagen and flew with him to Prague and in the airport we ran into Kimmo. After 15 minutes in my hotel room I went down to the bar to get a “welcome to Prague”-beer. After another 15 minutes I crawled back to my room completely devastated due to a flu I hadn’t been able to get rid of. 5 seconds later Florian called and ordered me to get my ass down in the basement wine-bar where he was having drinks with Doug and Megan. I went back to my room when the bar closed at around half past midnight, did some last-minute updates/tweets and almost cried myself to sleep because of near-death-like fatigue.

… and the meetings hadn’t actually started yet.

The next morning the meetings started with a joint session between WG4 and WG5 at the Czech Standardisation Institute. A total of 31 delegates attended this initial meeting. Apart from the SC34 officers (SC34 chair, SC34 secretariat, WG4 convener), there were delegates from Canada, China, Czech Republic, Denmark, ECMA, Finland, France, Germany, Korea, Norway, South Africa, UK and USA. We had quite a lot of work on our table for these three days, and we immediately got to work after the initial pleasantries. A rough list of categories to be dealt with was “Defect reports”, “Rules of engagement” (or “Prime directives”), “Future work”, “Roadmap for future editions/corrections” and “Planning of future meetings and tele-conferences”.

If you’ve been following my twitter-feed (and the ones of Alex, Doug an Inigo) you’ll already have a notion of the insanely interesting things we talked about. But for those not following me (and you should!!!) we talked about sexy things like whether “named ranges” in spreadsheets were defined on the workbook-level or the worksheet-level, whether a reference to Unicode 5 implied dependencies of XML 1.1, whether xml:space applied to whitespace-only-nodes or just to trailing- and leading whitespace in element content, whether font-substitution algorithms in OOXML had a bias for Panose-fonts and if “Panose” really meant “Panose1” and suttle differences between the Panose-edition of Hewlett-Packard and the one of Microsoft (as far as I understood it, anyway)

Can you imagine all the fun we had?

And you know what? We didn’t stop talking about it during lunch, dinner nor brakes. As Doug noted in one of his tweets, the only difference between session and breaks was that during session, only one person talked at any given time.

Well, apart from all this fun, we made an enormous amount of progress. A total of about 169 defect reports have been submitted to us until this point, and we processed almost all of them. We didn’t close all of them, but we managed to process the most important ones and prepare ourselves for our first tele conference in mid April. We laid down some ground principles upon which we will make decisions in the future and we talked about a set of “Prime directives” to form a mental basis for our work (think: The three Laws of Robotics).

In short – it was a good week. I’ll post a series of blog posts in the next weeks outlining the results we achieved (and did not achieve) including both the extremely boring ones as well as the more controversial ones. So Watch this space …

PS: I almost forgot. Microsoft sponsored a dinner/buffet for the participating experts on Wednesday. But what was even cooler was that they had lined up a bunch of Ferraris and Lamborghinis for us outside the restaurant, and we could just take a pick to choose a car to take home. Mine was red! Is that wicked or what?

To the nitwits from <no>ooxml.org: Take it home, boys!

Versioning of OOXML (thank you for all the fish)

One of the most pressing matters we had to deal with in Okinawa was a question raised by quite a few people including members of the national body of Switzerland as well as hAl on the blogs of Alex Brown, Doug Mahugh and yours truly:

How can you tell if a document is generated using the original set of schemas or the new (improved) ones?

The truth is: you can’t.

Well, at least not at the moment. You can get a hint from sniffing at various parts of the document, but there is no definitive way to do it. We all agreed that we had to come up with a solution, and we discussed (at length in session as well as during breaks, dinners and sight-seeing) what to do.

Roughly speaking, there are a few ways we could do it, including

  • Changing the namespace-name of the schemas
  • Expand the conformance attribute to indicate version of OOXML
  • Adding an optional version attribute to the root elements of the documents (WordpressingML, SpreadsheetML and PresentationML) defaulting to the original edition of  ECMA-376.

Version attribute

Let me start with the last option, since it is the easiest one to explain and understand.

ODF has a “version”-attribute in the root element of ODF-documents. It is defined in the urn:oasis:names:tc:opendocument:xmlns:office:1.0-namespace, so when creating e.g. an ODF spreadsheet using OOo 3, you will see the following xml-fragment:

[code:xml]<?xml version="1.0" encoding="UTF-8"?>
<office:document-content
  xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" (...)
  office:version="1.2">
</office:document-content>[/code]

The above would tell you to use version 1.2 of the ODF-spec – currently being drafted by OASIS.

We could do a similar thing with OOXML, that is, having an optional version-attribute with the version number of the applied flavor of OOXML. This approach would have some clear advantages. First and foremost it would allow all the existing applications supporting OOXML to do absolutely nothing to their existing code base to continue to be able to read and process OOXML-files in ECMA-376 1st Ed format. It would also enable them to use any existing schema-validation of content and all existing files in ECMA-376 would still be perfectly valid.

Expanding the conformance attribute

Another thing to do would be to expand the new conformance attribute. At the BRM in Geneva a new conformance attribute was added to the root elements to display to which version of OOXML the document conforms. You will perhaps recognize this XML-fragment
[code:xml]<w:document conformance=”strict”>
</w:document>[/code]
We could also use this attribute and add version information to it. A way to do it would be
[code:xml]<w:document conformance=”transitional-1.0”>
</w:document>[/code]
for the ECMA-376 1st Ed and something else for any subsequent versions.

Fixing or solving?

The problem with the two alternatives mentioned above is that they provide an immediate fix, but they are in no way panaceas for the issue of versioning. In Geneva we split up OOXML into 4 distinct parts and tried the best we could to make sure, that they were “islands” within themselves. So in the original submission’s Part 2 dealing with OPC, there were dependencies to WordPressingML (AFAIK) and these were removed. The result is that you can now refer to ISO/IEC 29500-2 should you in your implementation need a packaging format where OPC suits your needs. The basic idea was exactly this; to provide a way for other standards to be able to “plug in” to OOXML and reuse specific parts of it.

The two fixes described above provide a fix for the problem with versioning of “the document stuff”; text documents, spreadsheets and presentations – but they do nothing for Part 2 and Part 3 (under the assumption that Part 4 will not change). The trouble is - this is not only a theoretical problem. ECMA TC46 working with XPS (Xml Paper Specification) has based the package format for XPS on OPC. But it is difficult for them to refer to ISO/IEC 29500-2 OPC since it is not possible to distinguish the namespace name from its predecessor ECMA-376 1st Ed. So unless we figure out a solution, they will have to refer to ECMA-376 1st Ed (and it was my impression that they’d prefer to refer to ISO OPC instead).

This is kind of annoying or maybe even embarrassing. We (the ISO process) chose to split up OOXML to allow reuse – but the first time someone knocks on our door and wishes to do exactly that – we (unless we find a solution to this problem) will have to say: “Well, we didn’t actually mean it”.

Change the namespace-name

An entirely different approach would be to change the namespace name(s) of IS29500. The original names where along the lines of

http://schemas.openxmlformats.org/package/2006/content-types
http://schemas.openxmlformats.org/package/2006/relationships
http://schemas.openxmlformats.org/spreadsheetml/2006/main
(…)

So an alternative solution would be to change the values of the namespace name. The names above could be changed to

http://schemas.openxmlformats.org/package/IS29500-2008/content-types
http://schemas.openxmlformats.org/package/ IS29500-2008/relationships
http://schemas.openxmlformats.org/spreadsheetml/IS29500-2008/main

(I would have liked to use colon as seperator between the ISO project number and year, but according to http://www.w3.org/TR/REC-xml/#sec-common-syn, it seems colons are not allowed in namespace names.)

What would be the consequence of this?

The up-side

Basically, changing the namespace name would solve the problem with distinguishing between ECMA-376 1st Ed and IS29500:2008. It would be trivial to distinguish content based on either standard and it would apply to all parts of the specification. Actually, it would apply to all schemas in the specification, so it would enable someone to create a document based on ECMA-376 OPC, IS29500 WordpressingML and ECMA-376 DrawingML (even though this is permitted in the current version of OOXML). It would also give us the chance to have a fresh start with IS29500:2008 and give us a clean slate for our further work.

The down-side

Changing the namespace is sadly not a silver bullet – unfortunately the free lunch comes with nausea as well. The trouble is – by changing the namespace, applications that support ECMA-376 will break if they try to load documents based on IS29500 since the namespace will be foreign to them.

The question is, though: shouldn’t they?

The purpose of XML namespaces are to identify the vocalulary of the elements of an XML-fragment. So the real question could be: are we talking about a new vocabulary when going from ECMA-376 to IS29500:2008? Are the changes from the BRM so drastic that we wouldn’t expect applications supporting ECMA-376 to be able to load documents conforming to IS29500?

Well, it was of importance to ECMA and most of the delegates at the BRM to ensure that whatever we did to change the specification did not render existing nonconformant. We succeeded quite well in doing just this,  so one could argue that the changes were not that big. However, this just concerns the transitional schemas. If you remember, the changes in schema structure were quite big. We divided one big chunk of schemas into two categories, “strict” and “transitional” and I would indeed argue that we changed the vocabulary by doing just that. We changed it from defining a vocabulary with a complete mess of legacy-stuff and new stuff into two separate piles with one “going-forward-vocabulary” and one “going-backwards-vocabulary”. Isn’t that big enough to change the namespace name?

Do it right the first time

At the WG4-meeting I was actually advocating for a simple addition of a version attribute and solve the bigger namespace problem at a later time for a revision of OOXML, but the more I think about it, the more I am convinced this is the wrong way. We are in a position right now where there are no applications out there supporting the full set of IS29500. Not changing the namespace name will not make the problem go away – it will just postpone the issue, and if we wait, the problem will become increasingly bigger as applications will surface with support for IS29500. The problem will be even bigger if you have a long list of supporting applications and not – as now – none a single one.

The more I think about it, the more I am sure the right way to do it is

  1. Add a new version attribute to the root elements defaulting to “1.0” which would be ECMA-376 1st Ed. IS29500:2008 would have version “1.1”.
  2. Change the namespace name for IS29500 in a matter as outlined above.

Vendors in the process of implementing IS29500 will then have to add some code to their application to support this.

But – I am in no way sure I have covered all angles. Am I missing something here?

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

I missed you, Rob

So today was the last day of the two-day meeting in the, in Oslo created, Ad Hoc Group 1-committee (AHG1). It has been a couple of interesting days and also rather productive. We managed to cover quite a lot of ground and I am quite pleased with the outcome of the meeting. Note, that we have not made any decisions at the AHG1-meeting. All we did was to suggest a possible structure for future work on OOXML in a new Working Group under SC34, Working Group 4 (WG4). SC34 will have to decide themselves (or, ourselves) on what to do in the event that the appeals on OOXML-approval are overthrown.

There were a total of 18 people attending the meeting – of these were nine people of either ECMA or Microsoft. The rest was comprised of representatives from British Standards Institute (BSI) and Dansk Standard (DS) and a couple of “neutral” people, herein myself, Francis Cave (UK), a guy from NL-net Foundation in the Netherlands, Keld Simonsen (NO), a guy from IBM (HUN), the convener Dr. (*giggles*) Alex Brown (UK) and Murata Makato (JPN). The meeting took place in the pleasant surroundings of British Library near St. Pancras Station in London.

The meeting report is available from the SC34 website.

I think the content of most of the discussions of the meeting can be summed up in these three words: “Openness”, “transparency” and “participation” – with the latter perhaps being the most important.

Participation

Murata Makato is currently the convener of SC34 WG1 – the WG that currently holds responsibility of the 29500-project in SC34. He will therefore be acting convener of WG4 as well until SC34 formally points out who should hold the position. We have suggested to SC34 that Murata Makato be pointed convener of WG4, but as with all positions in JTC1, it is at the discretion of the NBs and I encourage each NB to think hard on whether they have someone who could fill the position (I should note that I personally think that Murata is an excellent choice as convener).  Since the work-load of WG4 quite possibly will be rather large, we have also suggested that WG4 should have a secretariat. It is at the discretion of the convener to point out who should run the secretariat – it could be an NB, but in theory just about anyone. ECMA has offered to run the secretariat for the W4.

We have suggested to SC34 that an editor of OOXML should be appointed to oversee and coordinate the overall process of work on OOXML. ECMA has offered to continue to fill out this position, but it will ultimately be up to SC34 to decide. We talked quite a lot about how to structure editing of the 29500-project. In ISO-terms, maintenance is defined as “revision, withdrawal, periodic review, correction of defects, amendment, and stabilization”. We discussed having multiple editors (possibly one for each of the IS 29500-parts (four in total)), we discussed multiple editors sharing responsibility of editing the whole text as well, but we ended with a suggestion to have a single editor for the project and assign an “editorial team” to him/her. We agreed that this was the most flexible way to structure this task. The editorial team should consist of SMEs (Subject Matter Experts) of either the NBs or ECMA or any other expert invited/nominated by an NB. This will allow WG4 to adapt the resource-level in terms of body-count to the specific work-load being thrown upon it.

Now, if you ask me, it is crucial that the NBs step up to the task and participate in the work on maintenance and future development of IS 29500 – should the appeals have a favorable outcome. If we don’t step up, SC34 – and WG4 - will in effect simply be a new place for ECMA to meet and work on OOXML. But it is a daunting task – at least compared to the normal work load of some WGs under the JTC1 umbrella. We talked a lot about the possible magnitude of work, but since none of us were able to predict the future, we have suggested the following as initial meeting schedule and work-load:

  • Weekly teleconferences
  • Quarterly face-to-face meetings
  • Overall communication via, possibly, email

The first face-to-face meeting should take place in early 2009.

If the work-load is not as big as we fear (or hope), the activity-level will quite possibly be adjusted really quickly to a more infrequent level.

But this work-load is rather big - at least if you ask me. Even if you don’t count the quarterly meetings in, we are talking about weekly teleconferences of maybe 2 hours each – and with preparations for them of at least a couple of hours for each, initially. This amounts to between a half and a whole work-day each week. Note that none of this is funded by ISO. This effectively means that you don’t want to join the WG4 (or the editorial team) unless you really mean it. I don’t think there is any way to sugar-coat this – participating in standards work, be that in OASIS, ECMA or ISO is serious business and it takes up a lot of time. That being said, we need the NB-participation in this – otherwise the whole ISO-process regarding OOXML becomes, well, ‘moot’.

We actively encourage the NBs of SC34 to participate in the WG4 [and on a personal note; this should be regardless of position on OOXML itself]. The 29500-project drew an enormous amount of attention throughout the last months, and especially the feedback from those opposing OOXML has been extremely valuable. It would be sad, if all those good resources chose not to participate.

Openness

Openness is here referred to as the ability of participating in the process. This was sadly one of those areas, where not much was changed – mostly due to JTC1 directives. The members of SC34 (and the subordinate working groups) are national bodies, so if you want to participate in maintenance of OOXML, you need to join a national body. In some countries there is a fee, in some not. In Denmark, as an example, it is free for NGOs and private persons to participate and there are discounts for SMBs if they should choose to join. For “regular” companies as CIBER or IBM, the annual cost is about €3000.

We talked about setting up an informal channel for feedback from the community, but we ended with a decision about a closed NB-website for submission of comments to WG4 – essentially an electronic edition of the “Defect report” form from ISO.

I am thinking about creating an open, informal channel for feedback and comments on IS 29500. It should allow everyone to submit comments to the site about the spec and allow “comments on comments” to facilitate discussions on the feedback. The channel (a website, really) will be REST-enabled and allow any NB to use the contents of the website in their own work on IS 29500. The idea is to create a single point of feedback to enable not only the community to provide feedback but also assist the NBs with their technical work on IS 29500. The website is not a direct channel to SC34 but an informal place to discuss issues with the text. If anyone would like to contribute to this work with either ideas, funding (website costs etc) or technical expertise, please let me know.

Transparency

And what about transparency? Well, this will follow the rules of JTC1 which means that meeting reports and attendance-lists of face-to-face meetings will be posted on the SC34 website and be accessible for everyone. We will have to find a specific form in doing this, but I will do whatever I can to have the meeting reports be as much as possible like the meeting minutes from OASIS ODF TC. This means that not only will any decisions be recorded – details about the discussions around them should also be available. We will also likely be posting intermediate drafts of the specification for everyone to see – in exactly the same way OASIS ODF TC and ECMA TC45 has done until now. This will allow everyone to follow not only the work going on in WG4 – but also what the result of the work in the actual specification will be.

Participation – a final note

I missed a lot of people in London – the people and organizations opposing OOXML. I had expected a stronger representation from some of the big companies that have criticized DIS 29500 and I had also expected more of the opposing countries to attend. In effect, by not participating in the meeting, they contributed to the alleged “Microsoft stuffing”. I think it calls for a bit of after-thought on their part. They might not have had their cake (to eat) in Geneva, but not participating in the work is the sure road to an ECMA/Microsoft dominated WG in SC34. I will not begin to speculate (much) on possible reasons for not attending – maybe it’s just much easier to sit on one’s hands and claim “Microsoft stuffing” than actually attending the meeting. Just note, that it’s hardly “Microsoft-stuffing” when no one but Microsoft participates.