Participation, participation, participation

By Rick Jelliffe
October 29, 2009 | Comments: 12

IBM marketing guy Rob Weir has half of a new series of blogs The Final OOXML Update. up.

Readers may be surprised that I agree with many of the points he makes.

The Importance of a Balance of Interests

In Part I he mentions issues about the domination of standards committees by a limited number of players. This is an issue I certainly think is important, and of concern, and I have blogged about it multiple times. The main difference between our views is that I think Weir sees things primarily in terms of competitive corporations, while I see vendors and users as opposed: to Weir a balance of interests is basically satisfied by a multiplicity of vendors being present (even if most of them are using the same code-base) if I understand him correctly, while to me a balance of interests is satisfied by having adequate non-vendor involvement. (He thinks a committee is balanced if it has people like him on it, while I think it is unbalanced if it has no people like me on it!)

I have raised these issues many times before, and my answer is still the same: at the end of the day, what is needed is more participation especially by governments and non-vendors. Vendors are not credible when speaking for their users, because they don't: they speak for their interests in trying to get, satisfice and keep users. Microsoft, IBM, Sun, Apple, none of them can speak for their users let alone the broader community of their non-users.


Here is what I wrote about Concentration the ODF TC and it applies just as much if you cross out ODF and put in OOXML:

About six months ago, I put the boot into the ODF TC for not being representative enough. The laudable participation by a couple of core vendors was not being matched by participation by other kinds of stakeholders, in such a way that would make it difficult for those vendors not to get their way on any issues that came up.

You don't have to see this as some kind of conspiracy by the vendors (Sun and IBM); it is perhaps more like the old "Carry On" movie gag of the hapless soldier volunteering by having everyone else in line step back when volunteers are called for.

The solution is more participation by stakeholders other than software developers, and more participation by a broader range of vendors, and more participation by non-commercial interests, and more participation by end-users: any of the above!

I have no objection to the idea that if a group is in fact over-dominated by a particular set of stakeholders, even though this may be caused innocently because the other stakeholders are disinterested in participating, that it alters how successful the standardization process was. (Indeed, I wrote about it two years ago.) The BRM is so compelling because of the hundreds of participants and multiple National Bodies, for example: it's resolutions must be taken very seriously.

The Need for Continued Participation

In his Part II Weir mentions how unsatisfactory the ISO procedure was that meant that the OOXML BRM (Ballot Resolution Meeting) findings were not first incorporated into a final text that could be seen before voting. I agree, and Weir notes glumly that the ISO procedures have been changed in this regard.

However, as I noted at the time in The Perpetual Ballot Resolution Meeting, the idea that the BRM was the last chance for changes, or the only opportunity for review, is one that causes unnecessary panic. But there is a maintenance process that sifts through these issues. So again, what is the solution? Participation

I don't know why, if you think your opponents are tricky bastards, you would leave them alone for a year, then suddenly complain that they have too much influence? Go figure.

The Need for Follow Through on the BRM Decisions

In Part III Weir looks at some particular issues that have come up as part of maintenance, and looks at them in the light of the BRM. I think this is a very good and important thing to do, though of course our views of the BRM are rather different.

I am also quite concerned about some aspects of the forthcoming Corrigenda and Amendments. Of course, I am not concerned that they exist, that is the point of the Perpetual Ballot Resolution meeting. National Bodies are currently discussing their ballot positions. I believe the next SC34 meeting is in Paris in the first week of December. I hope that National Bodies and Liaison Groups, especially those who attended the BRM, will be able to participate.

To be clear, I think most all the individual items in the Corrigenda and Amendments are non-controversial and deserve support. I don't know that I have any trouble with any item in the Corrigenda. But some amendment items are definitely tricky (not in the sense of someone trying to trick you, in the sense of them being difficult to think through): JTC1's Yes with Comments and No with Comments mechanism is available for individual item improvements or vetoes, and WG4 is an ongoing group so objections of a fine-tuning nature are better handled in the immediately following round of maintenance.

And to be concrete, here are the Corrigenda and Amendments: they are limited in scope particularly to issues arising from the BRM (there are a ton of other defects of course):


But I do think about three big background issues. (I hope without the same hysterical tendency that brands every mistake as a lie, every cockup a conspiracy, every criticism an attack, and every divergence from party line as a betrayal, as the reader may see in some commentators' writings.)

The first is that the initial ballot, the BRM and the subsequent ballot on IS29500 clearly did not accept the idea that it was good enough for IS29500 to merely replicate Microsoft's OOXML: not for Strict nor even for Transitional. Similarly, the idea that IS29500 should be entirely "aspirational" was not accepted. Instead, the BRM came up with the notion that the future was with a "Strict" version of OOXML that had several changes in syntax (and dropped VML and so on) and that other features would be noted in a Transitional section, a superset of the Strict.

Some of the Amendments would change this: I don't actually have any objection to any bogus parts of Transitional being removed or corrected (where DIS29500 says one thing in the name of compatibility, but it was inaccurate against what Office 2007 does) but changing the subset/superset relationship is a big step. SC34 feels it is a technical necessity (because of a report from a vendor, by the way, no Microsoft.) What changes is the subset/superset relationship.

The second issue is related. Any tendency to see Transitional as something with a life, or something to be standardized by national standards bodies needs to be thumped on the head. Some NBs need to get out their priests.

I wrote about this earlier Should OOXML be a national standard? The really regrettable thing that has come out, is that the editor failed to incorporate the text from the BRM that said that Transitional was, err, Transitional. This is fixed in the Part 4 Technical Corrigendum. And I would imagine it would take a bit of chutzpah to make any argument that Transitional should hang around longer just because the consolidated text left it out.

But I think any National Body that has made a National Standard of IS29500 may need to re-visit the decision, as far as Part 4 Transitional features, goes, in the light of that missing text. As it says The intent of this Part is to enable a transitional period during which existing binary documents being migrated to ISO/IEC 29500 can make use of legacy features to preserve their fidelity, while noting that new documents should not use them. Part 4, if anything, is a list of feature that should be avoided and to mandate them for new documents in any way goes against the standard as voted for.

To me, any National Body that did not go through the published text of IS29500 and verify that their issues as resolved at the BRM had not been satisfactorily implemented (and therefore raised a Defect Report) have not done their job. I certainly checked on our Australian issues.

The third is the change in namespace for Strict. For a couple of years now, I have been making little warning noises that I thought we were at the limits of what our schema languages conveniently allow us to represent. I blame W3C XML Schemas to some extent, but the biggest reason is the blind desire on the part of schema-makers and infrastructure makers to avoid any issue of schema evolution apart from the most trivial.

For example, I have said in the past that I think that both ODF and OOXML should have both DSRL and MCE built-in, and I have given some ideas on schema langages for namespace superset/subset relationships. I think the issue of OOXML Strict changing namespace, and therefore becoming incompatible with any existing OOXML software even if it does use MCE (unless there is a total duplication in Transitional) is an example of this crisis. But no-one else regards it as a crisis in our infrastructure. They would prefer to treat it as a challenge to be overcome or somehow unavoidable. Or non-existent.

So what should be done? The answer now, again, is participation. If you are concerned about any of these issues, make sure your national body is participating in the current ballots: if you are not a direct participant, send in you view to the technical committee via your national standards body. (I mean a real view on some of the technical issues, not a diatribe on issues not under discussion.)

The hare and the tortoise

Weir's final point is also one that I am happy to second:

OOXML will be extended by Microsoft much faster than it will be standardized and corrected by ISO. This will make the ISO version of OOXML, currently not supported by Microsoft, even more irrelevant in the future.

This is certainly a possibility, and one that is in fact being discussed already. Of course, IS29500 has a good story for handling extension features with graceful degradation to standards: the MCE features that allow multiple parallel versions. And new features on the market is headache for ODF too, of course: think SmartArt. Or think of the all the changes recently announced for the new formula functions for Excel: how does will WG4 cope with them? How will OpenFormula cope with them? How will governments who want to enforce standards for a level playing-field cope with them?

And here participation is only part of the answer. The NBs and governments who supported IS29500 need to follow through on their goals for adopting IS29500, since they also supported IS26300.

Was the lack of documentation just an excuse?

For example, one of the big selling points for IS29500 was that the Open Source developers had long said they were being hampered by a lack of documentation. But in the two or so years that the ECMA and ISO specifications have been out, have many Open Source project actually used the information much? (I was looking at recent drafts of Open Formula, and found no mention of IS29500, for example, which I found incredible.)

If opening the format floodgates has been met with disinterest, does it suggest that the FOSS people were just bleating to make excuses for product shortfalls? That, for documents at least, the critical path or congestion point has not been the availability of information or IP, but the lack of manpower or adequate processes to harness the million eyeballs?

IS29500 removes that excuse.

But if the primary purpose of IS29500 was to provide documentation, whether or not that documentation was in fact so critical (autospacelikeWindows95 important? pulleeeeze!) then that has been done, with some gaps that can be addressed. If an NB voted in order to get the information out, then now that it is done, it is not so important that IS29500 continue.

In fact, that is exactly what I think should happen to Part 4 of IS29500, the Transitional Migration features. People can still reference the 2008 version of the standard, as amended. But I don't see any value in Part 4 remaining an ISO standard in the medium term. I think WG4 should get a plan together to remove Part 4 entirely. ECMA can maintain it separately if it is important for them. Part 4 is just a burden and distraction on the standards process.

The trouble I see with Part 4 is that it will confuse Microsoft executives. Lead us not into temptation they will undoubtedly be praying by their bedsides each night for we love wriggling and we are atop a cliff. What the BRM and the final IS29500 ballot did not do was say that the existing OOXML format was acceptable as-is as the basis for future documents: only after the transitional features had been removed was it OK.

Is SC34 WG4 an effective mechanism for instructing Microsoft on necessary format and feature changes?

Another reason that a NB might have supported IS29500 was because they wanted to have a more direct input in the features, schemas and notations generated by Microsoft's products. They wanted more input, and less dictation from Microsoft.

I have not seen any indication that this is something that Microsoft is vigorously pursuing: where is the consultation on the new features in Office 14 for example? To be fair, I believe Microsoft did give various briefings to sc34 WG4 participants at various times, and the WG4 was focused on getting the BRM corrections out the door.

But Weir's comment about catch-up is one that I have raised myself privately. Though, again, the availability of MCE means that if a new feature is always used so that its elements are accompanied by an MCE fragment in the standard format, the new features can be down-converted to standard applications or simpler ones like ODF without difficulty. (Just not round-tripped.)

MCE changes a lot, I think. It provides a way for Microsoft to outrun ODF systems on features, while at the same time keeping readable by standard systems.

But I think that NBs that voted for IS29500 because they wanted to make sure that Microsoft cleaned up its formats and feature sets will not get what they want from SC34 WG4 unless they use the only gun and only bullet that it provides: participation.

Boycott Transitional

So where does this leave us?

I have deliberately avoided trialing Office 14, or looking at its feature set in toto. So I am saying this purely out what I believe was the intent of the BRM. I don't know what file formats Office 14 will provide.

The instruction of the BRM, that Transitional is not to be used for new documents, should be taken seriously by any government that wants to adopt open standards. An application that generates OOXML Transitional for new documents (by default) should not be acceptable, because it goes against the clear instructions of Part 4 of the Standard. (These instructions are being restored by the current Corrigenda.)

That this information was missing from the Part 4 as published, due to a serious mistake by the editor, by ITTF and perhaps by a lack of diligence by the Canadian NB to follow it up, changes nothing. The wide participation and publicity of the standard robs that excuse of any power. (Indeed, the use of the word "Transitional" should be enough of a give-away.)

To put it bluntly, if Office 14 (or a future OpenOffice ) generates OOXML Transitional for new documents but not OOXML Strict, the documents may conform to the standard, however the application is non-conforming.

To be clear, the specific text of Part 4 of IS29500 s1 "Scope" (as corrected) says of the transitional features that new documents should not use them. In particular: The features described in this Part shall only be used by documents of conformance class WML Transitional (§2.1), SML Transitional (§2.1), or PML Transitional (§2.1). These features are sometimes needed for high quality migration of existing binary documents to ISO/IEC 29500. The standard does not approve of Part 4 features except for these kind of import scenarios. The should is a little weak, and the shall not is directly tied to the scenario.

Of course, there are several other issues like this. It will be interesting to double check the issue of whether an Excel document using the new Excel functions is saved to OOXMl, it would still conform to the standard. I would presume not. Unless there is an MCE workaround, IS29500 conformance does restrict the kinds of changes that Microsoft can make to its formats without putting them through international scrutiny.

It will be very interesting to see if the European authorities clarify what their intent was when they called for Microsoft to standardize their file formats: was it just to put the information out there to create a level-playing field, or is there an expectation that the reputable standards body will take over stewardship of the format to actively reduce the control that Microsoft is allowed to have on the format. I suspect that Microsoft thinks the former is the case, while many other people might be hoping for the later.

But the one thing that Microsoft cannot be accused of, and that is a lack of participation, a fact its competitors and detractors need to treat seriously, rather than dismiss with a blast of insults.


You might also be interested in:

12 Comments

"Was the lack of documentation just an excuse? [...] If opening the format floodgates has been met with disinterest, does it suggest that the FOSS people were just bleating to make excuses for product shortfalls?"
The request for documentation was related to the *binary* formats. There was no request for *OOXML* format documentation, simply because when OOXML was accepted and published by ECMA, there was no software available yet to create OOXML documents... And in the meantime, ODF was available as an XML-based, documented and standardised format, so there was no need for OOXML, hence very limited FOSS interest for a documentation of OOXML.

Note that some documentation is now available for the binary formats, but too little and too late: the world has moved to ODF since then.

"a mistaken tactical diversion of resources away from ODF to OOXML for a year" I agree with you about this: it is a pity that ODF experts have been distracted from ODF to defend it against OOXML, but this was part of the plan of Microsoft, as ODF had several years of advance over OOXML.

"Participation, participation, participation" One one side, you regret diversion of resources from ODF, on the other side you claim that more ODF resources should be diverted to participate in OOXML committee work... You are contradicting yourself here.

"the one thing that Microsoft cannot be accused of, and that is a lack of participation" Yes, Microsoft can be accused of the lack of participation in OOXML work. If no one except Microsoft and partners is interested in OOXML at ISO level, it is because OOXML is a Microsoft proprietary technology disguised in an ISO standard. As OOXML only serves the Microsoft eco-system, it should have been "standardised" at ECMA level only, not at ISO level. SC34/WG4 would not exist by now if Microsoft had not misbehaved and forced OOXML through ISO's throat.

"I don't see any value in Part 4 remaining an ISO standard in the medium term. I think WG4 should get a plan together to remove Part 4 entirely. ECMA can maintain it separately if it is important for them." Your are spot on ! I fully agree with this (see above). Unfortunately for Microsoft, the main reason they provided for the existence of OOXML as an ISO standard was the need to ensure “100% percent compatibility” with the legacy documents. Once Part 4 is removed, the main reason for the existence of IS29500 disappears, and you can as well remove the other parts. Good riddance...

"Was the lack of documentation just an excuse? [...] If opening the format floodgates has been met with disinterest, does it suggest that the FOSS people were just bleating to make excuses for product shortfalls?"
The request for documentation was related to the *binary* formats. There was no request for *OOXML* format documentation, simply because when OOXML was accepted and published by ECMA, there was no software available yet to create OOXML documents... And in the meantime, ODF was available as an XML-based, documented and standardised format, so there was no need for OOXML, hence very limited FOSS interest for a documentation of OOXML.

Note that some documentation is now available for the binary formats, but too little and too late: the world has moved to ODF since then.

"a mistaken tactical diversion of resources away from ODF to OOXML for a year" I agree with you about this: it is a pity that ODF experts have been distracted from ODF to defend it against OOXML, but this was part of the plan of Microsoft, as ODF had several years of advance over OOXML.

"Participation, participation, participation" One one side, you regret diversion of resources from ODF, on the other side you claim that more ODF resources should be diverted to participate in OOXML committee work... You are contradicting yourself here.

"the one thing that Microsoft cannot be accused of, and that is a lack of participation" Yes, Microsoft can be accused of the lack of participation in OOXML work. If no one except Microsoft and partners is interested in OOXML at ISO level, it is because OOXML is a Microsoft proprietary technology disguised in an ISO standard. As OOXML only serves the Microsoft eco-system, it should have been "standardised" at ECMA level only, not at ISO level. SC34/WG4 would not exist by now if Microsoft had not misbehaved and forced OOXML through ISO's throat.

"I don't see any value in Part 4 remaining an ISO standard in the medium term. I think WG4 should get a plan together to remove Part 4 entirely. ECMA can maintain it separately if it is important for them." Your are spot on ! I fully agree with this (see above). Unfortunately for Microsoft, the main reason they provided for the existence of OOXML as an ISO standard was the need to ensure “100% percent compatibility” with the legacy documents. Once Part 4 is removed, the main reason for the existence of IS29500 disappears, and you can as well remove the other parts. Good riddance...

Luc: You are right that there were not many calls for the OOXML documentation to be released before OOXML itself was released. Except for the biggy of the European Union. And since the documentation was released at the same time as the applications, there was not much call afterwards: go figure.

And you are right that some of the negative comments about OOXML were not about OOXML at all, but about the desire for more binary documentation as being more important at that time for some commenters.

But since OOXML was also decried as just a binary dump, and therefore have mainly the same semantics as the binaries had, are you saying that the problem of the binary formats was really just one of syntax? I would find that surprising. Is the formula language so different between the binaries and OOXML, for example?

The incredibly important autospacelikeWindows95, that so many commentators and national bodies (notably excepting the Japanese who are the only ones the feature actually applied to) reported, was entirely about incomplete semantics, for example, wasn't it?

On MS's blame for the lack of participation by others, is this a general rule? So that the lack of participation at ODF TC is caused by Sun and IBM, for example?

I don't believe I did call for resources to be diverted from ODF, by the way. Why is it a zero-sum game? The point of calling for more participation is that the pie has to get bigger: more people from a broader spectrum.

B.t.w., Microsoft did not force OOXML through ISO's throat. It followed the rules under intense scrutiny, and JTC1 looked into the various NB complaints and found them based on mistaken ideas about what the process was. A compromise was reached on OOXML that, unless it is dismantled by a subsequent lack of participation, should be a little unpleasant for both sides.

Look at the premise of this blog: the potential issue of whether Microsoft will make Strict the default Save format for OOXML documents, as required by the BRM for an OOXML system, may indeed be too much for them to swallow. If it turns out that this is too much for MS, and they deliberately choose to be non-conforming in this area, would you then accept that actually the BRM and ISO process was not MS forcing anything down any ISO orifice, in the sense of MS getting everything they wanted?

Rick, Thank you for your reply. I think we agree on most things, with some perception differences.

About the calls for the OOXML documentation: don't get me wrong, it is a very good thing that both the binary and OOXML documentation are available. But publishing them at ECMA was fitting the need. Why claim also an ISO stamp, unless for marketing purposes ? Clue: it was not to ensure independent evolution of the standard, as shown by the current attendance to SC34/WG4 meetings (http://www.robweir.com/blog/2009/10/final-ooxml-update-part-i.html).

About "autospacelikeWindows95" and the likes: this was an example of the general lack of quality of the text. Most people were not claiming that this was an important feature to be documented, but rather that it is not acceptable in an ISO standard to include features related to a specific version of a specific product from a specific company. And *in addition* these features were even not described!

"On MS's blame for the lack of participation by others, is this a general rule? So that the lack of participation at ODF TC is caused by Sun and IBM, for example?" The general rule is that if a technology is specific to a single company, you should not expect the competitors to help developing this technology. For the ODF TC, the technology aims to be platform neutral, shared by several application providers. As such, you have participation from many providers (IBM, Microsoft, Sun, RedFlag, Novell, KDE...) as well as user organizations and individuals (see http://www.oasis-open.org/committees/membership.php?wg_abbrev=office).

"Why is it a zero-sum game? [...] the pie has to get bigger: more people from a broader spectrum" Unfortunately resources are not infinite. By the way, the best way to achieve getting together more people from a broader spectrum is to concentrate on a single specification, rather than developing concurrently two specifications, with additional work groups in charge of trying to define conversion rules between the two.

"Microsoft did not force OOXML through ISO's throat" On this one, I'm afraid that we simply have to agree that we disagree.

"would you then accept that actually the BRM and ISO process was not MS forcing anything down any ISO orifice, in the sense of MS getting everything they wanted?" My view is that MS wanted only one thing: a marketing claim that OOXML was an ISO standard. They already have everything they ever wanted from ISO.

Rick, I'm not in marketing, and never have been. I'm a Software Architect and work on ODF, the ODF Toolkit and with related development teams at IBM, such as Lotus Symphony. Though obviously a well-rounded engineer should be familiar with a range of adjacent fields, such as marketing, sales, IP law, communications, etc. It is all connected.

In any case let's use your criteria to see what would need to happen to get WG4 to have an acceptable level of balance. As I understand from your previous posts, you have a lengthy set of conditions for balance, including limits on total US corporations, limits on office suite vendors, limits on participation by single corporations and limits on participation of companies whose products are based on a single codebase. gGiven that Microsoft has 10 people in WG4 now, then how exactly do you achieve that balance? Certainly adding IBM, Sun or Novell employees would fail, since that emphasizes office suite vendors and large corporations even more.

If you really want to have no company have more than 25% of the participation on the committee, then you would need to match Microsoft's 10 with 30 other participants, and these would need to be predominately from non US-corporations, non-office suite vendors and non large corporations. Seriously, Rick, do really think WG4 should grow to have 40 or more members? And what then would prevent Microsoft from adding 10 more members? It seems that if Microsoft wants balance,then they can achieve it today. But if they want to dominate WG4,then there is nothing anyone can do about it.

Rob: 40 people? Yes indeed I would be much more comfortable with those kinds of numbers. That would be about 1/4 or less of the delegates to the BRM, for example.

I don't see why every government and military from every developed country or treaty organization does not have a delegate each, for example. (And one for the ODF TC too, and for W3C HTML WGs.)

That they do not is out of kilter with the business value of the formats to them as users. It shows they are not serious about standards or their value. (Marbux pointed out the code that the US Secretary of Commerce has an obligation to ensure balanced US representation on international standards committees, and adding delegates is presumably the method of choice for this.)

What is good for the goose is good for gander. On the number limits, I would certainly apply them to the primary ECMA OOXML and OASIS ODF committees alike, but I don't see why WG4 would be excluded now that it has become the forum for maintenance, within the limits of the obligations of technical experts and NB delegations.

B.t.w. my limitations were not on meeting attendance, but on formal votes IIRC. So for instance IBM could have 50 people at an ODF TC meeting to contribute expertise (the more lurkers the better), but a maximum of two would vote if any issues came up that required it, which I think was something Doug said Microsoft would be OK to do at the OASIS TC.

I look forward as always to reading a warm call for broader membership of all standards groups on your blog that includes the ones you co-chair.

Rick here are some responses from one government person..

"what is needed is more participation especially by governments and non-vendors..I don't see why every government and military from every developed country or treaty organization does not have a delegate each, for example"

You don't understand government, which doesn't have the resources or the money to hire or hold people who could do this. If someone is expert enough in standards to do this, they will have long left government service for something more lucrative.

"The instruction of the BRM, that Transitional is not to be used for new documents, should be taken seriously by any government that wants to adopt open standards"

OOXML in its entirety should never be used by governments for new documents. Leaving aside the fact its not an open standard the whole mess was designed to be compatable with binary documents, not to be used for new documents.

"But the one thing that Microsoft cannot be accused of, and that is a lack of participation, a fact its competitors and detractors need to treat seriously, rather than dismiss with a blast of insults"

Thats your least-informed statement of all. If Microsoft was interested in participation in an open standard it never would have created and pushed OOXML, it would have worked with the ODF TC to add features to ODF, and it wouldn't just show up at ODF TC meetings and pay lip service to participation by introducing proposals and then letting them drop before consideration.

No matter, OOXML is dying, as it should. It would be pretty silly of IBM and Sun to participate in a dying "standard" like OOXML which has almost no valid uses for anything. Most documents people create are NEW documents. That is what ODF is for.

Purported Govguy: Certainly governments cannot allocate resources entirely optimally, nor are the resources infinite. My point is not complaining that the world is not perfect, but that this is an important area where the more that governments and users avoid participation and leave it to imagined other people, the more likely it is that they will lose out.

Take ODF for example. IIRC it was only when South Africa's Bob Jolliffe participated that ODF got serious about encryption. Users (including govt users) have different priorities than vendors. No play, no win. And if they don't participate, they cannot complain if the result is not suitable for them.

Even if you think that OOXML is a waste of time, that does not provide an excuse for governments not participating on OASIS ODF TC, for example. If they are going to bet a large part of their whole information platform on ODF and it is still under development, they should grasp the opportunity. When we do government contracts, the tenders and requirements are often specified in minute and optimistic detail: how unbalanced is it for a government to avoid any participation in an unstable core technology?

@Rick: "I have deliberately avoided trialing Office 14, or looking at its feature set in toto. So I am saying this purely out what I believe was the intent of the BRM. I don't know what file formats Office 14 will provide."

Jesper Lund Stocholm had a look at the Office 14 files and writes: "I must admit that I am a bit disappointed. [...] I had expected more of the things we discussed at the BRM to be implemented. [...] It would have been a nice token of “good faith”. Now, we are basically left with nothing."
http://idippedut.dk/post/2009/11/03/Excel-2010-%28Microsoft-Office-2010-CTP-TO-do-list-%2801%29.aspx

So, it turns out that MS deliberately choose to be non-conforming. As Rob Weir wrote: "It appears that Microsoft got what they wanted from ISO and is moving on. Who said it would last more than a night?"

Luc: Yes, Jesper's is a good page for people to look at, and the comments are interesting.

Though I think he should point out that he is reviewing a beta of a product that is due for release in four to six months time (AFAIK: Wikipedia says 'Spring 2010'), and he is reviewing a version made before the recent Corrigenda and Amendments were passed and resolved.

The anti-Microsoft crowd tried to promote a fantasy about how bad the OOXML standard is, and the National Bodies and reviewers did not buy it. They tried to promoted a fantasy view of how the international standards system worked, and the JTC1 review did not buy it. They tried to promoted a fantasy about conspiracies and dirty deeds, and various reviews such as the UK High Court did not buy it.

But now that IS29500 is out (and corrected through the Corrigenda) the anti-Microsoft crowd finally has, *because of IS29500*, a set of objective criteria which they can reasonably use to make their case, if Microsoft is non-conformant. (And Microsoft has the same benefits too.)

IS29500 is a voluntary standard. Microsoft is under no obligation, except their multiple undertakings, to follow it. You can expect that they will try to weasel their way out of whatever is inconvenient (the way that the ODF people tried to weasel their way out of ODF's lack of an actual formula language.)

But it will be a test of the drafting of IS29500 and its schemas how much weasel-room there is, before people resort to talk of "the spirit of cooperation" and other fantastic conveniences.

Personally, I suspect that the change of namespaces for Strict OOXML may be the nail in the coffin for Strict OOXML: everyone knows it is a mad and provocative idea. But its virtue is that it makes more stark the kind of little bit strict, little bit transitional monsters that Jesper points out.

(My own preference would have been for spreadsheets to have an MCE element with a single element in wom specific new MustUnderstand namespace: existing conforming software that understood MCE would then reject these documents, and the forward compatablity problem of the new dates would be minimized. But, as I have mentioned before, I think the whole schema and processing infrastructure for namespaces is exposed as too poor to support the lifecycle requirements of standards for casual office documents.)

I appreciate this account and the commentary that has been tied to it.

There is one aspect that bothers me, and I will indulge my penchant for instant-design, having exactly the value that is being paid for it:

If Microsoft Office 2010 Word, Excel, and Powerpoint were to only save OOXML in IS 29500 strict (along with any appropriate use of MCE for newer-than 29500 goodies), this would severely impair down-level interoperability with earlier OOXML-supporting versions of Microsoft Office (which, from my point of view means all the way back to Office 2003 with the compatibility pack). That is unimaginable.

So I don't think this can be a black-and-white, all-or-nothing deal. I don't quarrel with the schema namespace change for strict, I just think that there is more transitioning involved to make it work.

It seems to me that, from a product acceptability point of view, the safest way of doing this is to save in the format received by default and to provide some modicum of support under Save As ... options. Enterprise and institutional adopters can use the adminstration provisions to adjust the defaults to their preference. Or certain mass adopters, such as agencies of the EU can bully Microsoft into restraining versions shipped to them right in the box. They'll get what they pay for too.

If it was up to me, the products would need a way to Save As ... Transitional and Save As ... Strict-Subset Transitional as well as Save As Strict. (I also have no idea how Microsoft Office 2010 and its successors will actually navigate this morass.)

It might well be that Save As ... Transitional would only do Save As ... Strict-Subset Transitional at some point, to hasten the the convergence on strict over time.

The features in strict that are not under transitional, to the extend that is the case, would be problematic.

There is, by the way, a missing provision of MCE that would make life much easier. It doesn't help down-level (because not in MCE down-level), but it helps at the same level and into the future.

If there were a way to conditionally select between xmlns:="" attributes so that the same prefix could be conditionally bound to different namespaces, it would be possible to switch among namepaces where the producer new that any of the understood choices sufficed.

There might need to be some additional MCE variability down in the weeds, but this would help avoid massive duplication of large elements in order to provide alternatives. It would apply easily to sliding into transitional if the strict namespace is not understood. It would also help with some use cases around attributes that carry prefixed formulas that might have to be declared as OpenOffice ones or maybe OpenFormula ones, when the formulas being used are the same for either namespace.

Of course, I have no idea how to actually accomplish this without some perversion of XML itself and of the XML Namespace specification. Hmm, there's a perverstion that *might* do this job without breaking namespace well-formedness. Unfortunately, this comment form is not big enough for the solution.

Dennis: Yes I would expect there will be a Save as for Strict and it can be set as the default at user option (i.e. making it the users' problem). And I bet they save the document in the same dialect it opened in, where this can be ascertained.

Practically: I think all the standards need to have DSRL, MCE plus the kind of namespace relationship declarations I have mentioned before, to cover the cases adequately. And I also think that processing languages need to allow somekind of partially-wildcarded namespace matching more easily.

But this is another of these areas where optimism drives us into a hole: we think it is bold to hope that there is no issue with versioning so we defer trying to fix it until it becomes a problem, by which stage it is too late.

There are a few attempts to address this, here and there with various degrees of success: XSLT has its forwards compatability stuff, XSD has its complex type derivation, some specs have mustUnderstand kinds of constructs, Schematron has its phases, I have mentioned ISO DSRL, and MCE is probably the state of the art at the moment.

News Topics

Recommended for You

Got a Question?