More thoughts on last weeks BRM

Article
03/04/2008

Here's a bit more information on the results of the BRM last week, and where we go from here. There were about 1,000 comments/issues raised last year with the spec, and starting last fall Ecma began posting responses and proposed changes to the specification to address the concerns. The final batch of responses was posted mid-January, and at that point Ecma had already begun discussions with the national bodies who had raised the comments to see if they were suitably addressed.

For the past two months, Ecma officially held 4 calls per week where national bodies could discuss the comments, and Ecma could explain their proposed resolutions. This meant that by the time we got to the BRM, the countries had time to find which Ecma responses they were not quite satisfied with, and raise those issues at the BRM. The purpose of this entire process is to make improvements to the specification, which in turn may lead countries to change their vote on whether or not they approve the overall spec.

While it's a matter of opinion whether or not the BRM itself was a success, in my mind a number very important things happened (I'm not sure if I'm allowed to mention countries by name in terms of the work done, so for now I will avoid it):

98% of Ecma responses approved – This was very important. The Ecma responses consisted of a number of changes to the specification in order to address the concerns raised by various countries. These were issues that one or more countries felt were problematic in the spec, so it was important to make sure the feedback from those countries were heard, and that the spec was modified to address those concerns. Most people at the BRM that I talked to agreed that without question, the changes proposed by Ecma made the spec better. Voting to approve a comment means that you feel the spec is better with the change than without. This is why it would have been odd to see the changes voted down, which would have meant countries felt the spec was better before the change. Some countries voted "yes" as the default for all the comments, some voted "no" as the default for all the comments, and most countries didn't give a default vote. Then the countries picked any individual comments they had reviewed where they in essence wanted to give a direct "yes/no" vote (overriding the default vote). It shouldn't be surprising that many countries only reviewed their specific issues, and in these cases they often decided to abstain from voting on the rest.
More changes were proposed at the BRM – There were a number of issues where folks wanted to see the proposed changes go further. Even in these cases, most of the countries felt that the Ecma responses made the spec better, so the original Ecma response was approved. We also would work in groups to add additional changes on top of the Ecma proposal. I'll now list some examples of these changes.
Transitional and Strict conformance – A number of folks weren't comfortable with the deprecated annex, and wanted us to go much further. So a few countries, with the help of Ecma folks came up with a new proposal where there would be two types of functionality: transitional, and strict. Conformance is defined in terms of transitional and strict, and there are even two versions of the schemas (transitional and strict). All of the legacy features that we had previously marked as deprecated, will instead now move into a new part called transitional. If you are going to create a strict document, than you are not able to use any of the transitional features (legacy compat settings; VML; old date bases; etc.).
Multi-part – We will split the specification into 5 parts. The five parts are essentially: OPC; Markup extensibility; Primer; Strict markup; Transitional markup. [update - I forgot that we changed this so that the primer is actually tied into the first part, so in the end we have 4 parts, not 5]
Dates – This was definitely a hot button issue. I worked with a large number of national bodies to come up with an updated proposal to solve the issue of dates in spreadsheets. One national body had an alternative proposal that we discussed, and between a number of countries we were able to come up with a fairly elegant solution. We introduced a new data type for cell storage which was "date". Previously dates had been stored as numbers, but with this new proposal, we have a "date" datatype, and the only allowed way of storing date values in cells of this type is with ISO 8601. We also simplified the concept of date bases, which are used when converting from a number into a date (mainly done in calculations). ODF has a similar concept where you can essentially set any date in history as the epoch. In our case there is only one way of doing this for strict documents, and the two legacy bases can be used, but only in transitional documents.
Accessibility – Thanks to two very influential countries, there have been a number of very significant improvements in terms of accessibility in the file formats. A new accessibility annex has been added, as well as some additional functionality for tables that helps make them much more accessible.
Function clean-up – We had a couple countries work on cleaning up some of the spreadsheet functions, as well as introduce the concept of prefixing (sort of like namespaces) for functions. This will help as we move forward with the next version of the spec, as we can start to add new/improved functions in the ISO prefix, and keep the legacy behaviors in the Ecma prefix.
Bitmasks – We had a national body propose a change to the spec in order to remove the use of bit fields, and instead use XML markup to represent the same values. Ecma had discussed this for a few weeks before the BRM with the national body, and that's how we were able to come up with a great joint proposal on these modifications. The original Ecma proposal was to not remove the use of bitfields, but to instead provide an XSLT in the annex that displayed how to work with bitfields. The feedback we received though in the weeks leading up to the BRM was that this did not go far enough, so in the BRM it was decided to actually change the format as well.

It was really a crazy week, and I know that a lot of people went without sleep as we worked around the clock to make the most of the opportunity. It was a chance for everyone to discuss additional things they wanted to see done with the spec, and also to meet those folks who will probably be involved in the next version of the spec as it enters into maintenance (assuming it is approved this month).

Thanks again to everyone who spent so much time helping to build a better specification. I know that it will continue to improve over the years, and I think we really have some great momentum now going into the coming maintenance.

-Brian

Comments

Anonymous
March 04, 2008
BRM delegate Antonis C. answered some concerns: http://elot.ece.ntua.gr/te48/ooxml/brm-clarifications and also links to the Greek date proposal. He also writes: "Brian Jones and Jason Matusow of Microsoft have said that the BRM was a success because it fulfilled its purpose, which was to make changes to the text. Although this is technically correct, if the original text got 1 out of 10 and the BRM managed to improve it to 1.1, it is somewhat misleading to call it a success. Brian Jones says that there was consensus in the changes. This is also true, but the reason there was consensus was that we quickly became disillusioned, lowered our standards, and only discussed modifications which we knew could pass within the given constraints."
Anonymous
March 04, 2008
It is simply unheard of in the standard circles that a draft standard is in such a turmoil (deprecated vs transitional/strict, accessibility, bitmasks, dates, *ml, etc, the list is endless) at the time when it should have been already set in stone for NBs to review, especially regarding these kinds of fundamental issues. Honestly, who believes that the Fast Track was the most optimal choice for OOXML, really? Why the rush, use the not-so-fast procedures and we all get a better spec, no?
Anonymous
March 04, 2008
I finally figured out why you think the BRM is a success, because no matter what happens, in the end Microsoft always gets what they want. It just feels like Microsoft has something up it's sleeve and Brian can't reveal what that is, but he knows there is something going on here that is more than what meets the eye.
Anonymous
March 04, 2008
"Why the rush?" Why do you even ask when we all know the answer? To prevent wider adoption of ODF and thus weaken MS Office's dominant and very lucrative market position.
Anonymous
March 04, 2008
This is so not what the fast tracking procedure is for. We're at the absolute final stage here, and you're proposing entire new field types? ODF may well have a "similar concept where you can essentially set any date in history as the epoch", but I'll bet it wasn't shoehorned in at the last second for ODF. Aren't fast track specs supposed to have two working implementations to get to this stage? And who's got a working implementation of this new stuff? Who's even got an Alpha of it ready yet? Cheers,

Mike

Anonymous
March 04, 2008
The comment has been removed
Anonymous
March 04, 2008
Perhaps if MS had done the date fix first, the last leap day would have gone more smoothly. Not sure about flaws in ODF - are they internal conflicts (same item with 2 names?) or does it encode data such that it cannot be decoded correctly, something else? On the subject of gaps, MS Excel 2007 still has no concept of units. The Office group did add a weak 'convert' function that stamped on the much more comprehensive one that I wrote.
Anonymous
March 04, 2008
In the BRM we updated the 'convert' function to include a large and well defined set of units. -Brian
Anonymous
March 04, 2008
The OOXML spec is now of a better quality, and seems to be closer to ODF than previously (surely the strict version). This is very good. If OOXML is rejected by ISO at the end of March, will all this work be lost? Of course not. The new text will simply become ECMA-376 1.1 instead of IS-29500 1.0. If OOXML is accepted as an ISO standard at the end of March, will MS Office make use of the strict version in April ? Of course not. It will take years before MS Office becomes fully compliant with ISO-OOXML-strict. And the more discussions take place, the better the text becomes, as explained by Brian above. I fully agree with him. So, why the rush ? Who will benefit from ISO adoption now ? Only the Microsoft marketing department, and nobody else, even not the MS Office users. It is still time to stop it. Reject DIS-29500 in March, keep the pressure on Microsoft, and continue the open process until the text becomes a good one. As Brian testifies above, THE OPEN PROCESS WORKS (the current quality would have never been reached by Microsoft working alone). A new ISO standard for documents is justified only if it is better than the current one. But there is still a lot of work needed to reach this status.
Anonymous
March 04, 2008
@Brian, The whole "if the same level of review had been applied to ODF" argument is getting a little old, Brian. You're telling us that OOXML is in better shape than ODF at this stage, because the former is (supposedly) getting lots of problems fixed, whereas the latter didn't have that happen? It's like saying that somebody who's in and out of hospital for major surgery every month must, thereby, be healthier than somebody who never needs to go to hospital at all. (Of course, the latter may always have some undiagnosed illness of which he's unaware; far more likely though that he just takes better care of his body). Gaps in ODF 1.0 there may well be (formulae etc). But that's a different case to a spec that actively contains nonsense, such as the aforementioned date issues ("thy shalt continue to pretend that 1900 was a leap year" etc). Too late to fix it all now. Way too late. You don't belong on the fast track with stuff like this. You never did. Get thee gone to the "normal" track with it. See you in a couple of years. Cheers,

Mike

Anonymous
March 04, 2008
Mike Brown: the human body analogy is tenuous. Standards are not living organisms! You seem to be implying that ODF was somehow "born" into this world, in perfect health, complete, without any birth defects: i.e., two arms, two legs, ten fingers, etc. That's simply not true. There is no such thing as "complete" for a standard. Standards come in all forms, unlike people, and, unlike people, are not generalists. They are tailored to special purposes. And furthermore, unlike people, they can be improved by insertions, deletions, and edits. If anything, what ECMA has done since the first draft is not surgery, but genetic engineering--something which, in theory, could also improve man, even individuals with a clean bill of health (e.g., in the form of more brainpower, a tail, reduced toothbrushing need, etc.)
Anonymous
March 04, 2008
I'm surprised that Office 2009 beta 1 is still out of the picture at this point. Isn't it including changes already? How can NBs spend their time cristalizing a specification whose only reference implementation is already at odds with it? Office 2009 beta 1 is supposed to become public right now. Why the silence? Example : Custom XML parts. There is no Custom XML part bindings for Excel and Powerpoint documents. (the only XML bindings are with external XML data sources, a feature that was available way before Excel 2007 existed). If the Office team has added them in Office 2009, it will cause an update of the file format (xpath attributes and so on).
Anonymous
March 04, 2008
I think several of the changes that came out of the BRM make significant impact on an implementation. So I would not expect any Office version to support the changes before the publication by ISO/SEC which might still be half a year away. Mayby even it might take up to MS Office 2007 SP2 before these changes are supported in MS Office.
Anonymous
March 04, 2008
The comment has been removed
Anonymous
March 04, 2008
@hal, "I think several of the changes that came out of the BRM make significant impact on an implementation. So I would not expect any Office version to support the changes before the publication by ISO/SEC which might still be half a year away." I am not talking about that. I am talking about the changes that are already checked-in in Office 2009, and that Microsoft is not talking about.
Anonymous
March 05, 2008
L' ISO vient de publier un communiqué de presse concernant le BRM qui s' est déroulé la semaine dernière
Anonymous
March 05, 2008
Patrick Durusau, editor of ODF 1.0 and the upcoming ODF 1.2, now supports approval of DIS 29500 in ISO. http://www.durusau.net/publications/onbeingheard.pdf
Anonymous
March 05, 2008
Davide, It gets pretty old responding to Rob's FUD everyday. His post might as well be about the "horrors of ZIP", or any other container format. His specific comments around the macrobutton field are pretty out there too. The field doesn't provide a way of storing anything, it's just a button that has a name and a command both stored as simple strings. If you are an application and you happen to know what the command means, then you can go ahead and run that command when the user clicks on the button. It's up to the application though to make sure that command is safe (just like the script tag in ODF doesn't tell you how to do security, it's up to the application). In reality, the main place I've seen this field used in the real world isn't even for running a command. It simply allows template authors to put placeholder text in like "click here and enter your names", where the entire text is selected when the user clicks, and then when they start typing the "button" is deleted and the text they type replaces it. -Brian
Anonymous
March 05, 2008
Brian, I know it's getting boring to see these kinds of postings popping up all the time on the other side of the fence but in this particular case the macrobutton was just a single example. The point was that all the information needed to implement macros in a compatible way is missing. PS. Again more noise, this time it's Brazil complaining the lack of mapping data between bin/ooxml docs: http://homembit.com/2008/03/at-the-end-what-we-did-in-geneva.html
Anonymous
March 05, 2008
Tough ones extracts from a recent post [1] of "the father of XML" (tm): "Treated purely as a spec for representing documents, OOXML is lousy. Frank Farance of the US ISO delegation was quoted as saying there are probably hundreds of defects. He’s being way optimistic. Every time I open it and start reading, I pretty soon come across some unforgivably-ugly piece of XML or hideous piece of English grammar or statement that just doesn’t make sense. There are going to be interoperability problems up the wazoo." "ECMA, which claims to be a serious standards organization, blessed the process of generating a XML dump of the internal data format and publishing it in six thousand poorly-edited pages, in well under a year. This seems wrong." "ISO allowed the draft to be substantially edited and enhanced after the initial ballot. This seems wrong." "It tried to repair the damage by stuffing 120 people in a room in Geneva for five days to address a thousand changes to the spec. This seems wrong." [1] http://www.tbray.org/ongoing/When/200x/2008/03/02/On-OOXML

disclaimer: “This is excerpted from Tim Bray’s On OOXML, which discusses both sides of the issue and which should be read in full for context.

Anonymous
March 05, 2008
Brian: your response to Davide about Rob Weir is typically disingenuous.

Zip is a container format, you are correct. It is not comparable to OOXML, which is a format for representing office productivity data, and allowing the editing of that data. OOXML obviously needs a lot more detail on the meaning of the internal data than zip does. Rob's point that this detail is missing in some very important places, is valid.
The MACROBUTTON discussion was just one example of a valid NB concern that got an unsatisfactory Ecma reply. His actual point, that "implementation-defined" content defeats interoperability if there is no way to identify and isolate that content, is valid.
The point of the whole post, which is that there were many important NB concerns which were not discussed properly at the BRM because of lack of time, is valid.

Anonymous
March 05, 2008
The comment has been removed
Anonymous
March 05, 2008
The comment has been removed
Anonymous
March 05, 2008
The comment has been removed
Anonymous
March 05, 2008
Hi Brian, Thanks for taking the time to respond to my comment. As I'm not an Office 2007 user, I was unaware that .docx files never contain macros until I just did a bit of research on it. That's interesting, but kind of irrelevant. How does Office 2007 "remove macros"? How does it recognise a macro for what it is? The MACROBUTTON, for example, contains a text field specifying the location of the macro. But even the format of this field is not defined! The validity of Rob Weir's point is that by not describing the format of that field, you make it impossible to parse the field and discover the nature of the target entity. I don't have any text to suggest about this particular issue. However, according to Rob Weir, 4 NBs did have suggestions, and they were denied the chance due to time constraints. THAT is the point! ODF and responsiveness are similarly irrelevant. The question is whether to standardise OOXML, and perceived shortcomings in "the other standard" shouldn't be considered. The real level of Microsoft/Ecma's responsiveness to change suggestions has been questioned in other fora. There are suggestions that after OOXML is standardised, Microsoft's incentive to be open will disappear and the responsiveness will wither. The maintenance plan (the draft proposal for which is unacceptable in some people's eyes) will not be discussed in ISO until later this year. Personally, I guess for now we just have to leave responsiveness out of the discussion altogether. Just on the subject of ODF, I love the term "snooze-rollered", and I do actually believe that apathy played some part in ODF's ISO adoption. It has also probably contributed to the slow pace of updates to ODF. I (and many others?) would probably never have really thought at all about issues surrounding ODF as a spec and its standardisation process, had it not been for the press surrounding OOXML! Perhaps, regardless of whether OOXML is approved by ISO or not, it will lead to more effort and focus being directed at ODF.
Anonymous
March 05, 2008
Rob, I agree with much of what you've said. You are a bit off though about the Macrobutton fields definitions. It states in the spec very clearly that it takes two arguments. The first is the name of the command or macro to run (and it's up to an application to decide what that command or macro means); and the second argument is the text to display, such as "click here". -Brian
Anonymous
March 05, 2008
My assessment: OOXML is intended to be a spoiler. It is not, and likely will never be implemented. It creates FUD for ODF, as a "standard" (but without a validation testsuite or reference implementation) can be used by Govs to mask their deals and by MS to claim to be open. Its a darn good marketing deal. Darn good - for one company and its NB stuffing partners. But Standards build marketplaces ... the better the standard, the bigger the marketplace - think oh ROADS, or the CDRom spec... I contend that if Microsoft would do drop MSOOXML and deliver products for the ISO ODF standard set (and playFair in growing that standard), that in short order the RealStandards (tm) marketplace would EXPLODE IS SIZE, and Microsoft could, with its Billion$ and Billion$ would have MORE business - a large share of a much larger, but SHARED marketplace then it does in its private Lock-in-Land. The landscape has evolved to "The whole world v MS" for standards based tools... think a castle under siege. Sooner or later the door is based in, you run out of food or the stones crumble. I believe Microsoft is failing its duty to its shareholders with their marketplace-limiting policies that drive customers to other vendors.
Anonymous
March 05, 2008
Rob, in regards to your question: "Do [standards] not grow and change as the demands upon them change?" The answer is no. Formats do grow and change, but the standard should remain the same. That's the whole point of a standard--predictability. It never changes. RTF 1.0, ODF 1.0, HTML 4 will always be the same. The same should go for "OOXML 1.0." When format needs evolve, it's time for a new standard, e.g. RTF 1.7, ODF 1.3, HTML 5, and "OOXML 1.1." Stephane: Do you have any reason to believe that Office 2009 will obsolete OOXML/DIS 29500 (dispositions included?) Presumably Office 2009 will include new functionality. However, this does not automatically mean a new format is necessary. (Many features can be implemented without any reference to formats, e.g. autocorrect, blog connectivity, SharePoint. And others, even major features that might seem to call for format changes, can make do without, e.g. Publishing Layout and Notebook views in Mac Office 2008.) In other words, even Microsoft introduces major new features with Office 2009, it may be able to do so without any changes whatsoever to the specification.
Anonymous
March 05, 2008
"In the BRM we updated the 'convert' function to include a large and well defined set of units. -Brian" There is no way to detect that a number representing a weight in pounds is being added to a number representing time in seconds. This is a huge gap and MS Excel 2007 still has no concept of units. As I mentioned over at Gainer's blog, MS Excel 2007 still forces mixing of row &| column titles with the spreadsheet data. How goofy is that in the 21st century? The gaps are huge.
Anonymous
March 05, 2008
@Luc Bollen "So, why the rush ? Who will benefit from ISO adoption now ? Only the Microsoft marketing department, and nobody else, even not the MS Office users."

What was the rush for ODF's ISO ratification? Why was ODF approved with huge missing pieces of even basic functionality and flaws? Why was ODF approved with the understanding that it would be "fixed" in ODF 1.1, 1.2, 1.3, etc (while OOXML is not being given that courtesy)? Can you be intellectually honest and admit that ODF was rushed, not because it was "perfect", but just to say "We're first!" so that lobbying of governments to mandate exlusive use of ODF 1.0 could begin (even though ODF 1.0 is nowhere near sufficient for gonvernment needs)? And you have the intellectually honesty to admit that, then you can see that the "rush" for OOXML's 1.0 ratification is to cut down on the amount of time IBM has to do its lobbying of governments to mandate exclusive use of ODF. Oh, I know you'd love for OOXML to take the "slow track", which would take what, 5 years?, which would give IBM plenty of time to convince governments to mandate exlusive use the broken ODF 1.0 standard, so that by the time OOXML made it through the slow track process, it would be irrelevant because it would be illegal for government use. We're not stupid, we know that's the scenario that the anti-OOXML forces are pushing for. Here are the facts: ODF 1.0 was rushed through the ISO process despite being the quality of a 0.7 spec, on the understanding that it would be fixed in later revisions. OOXML, on the other hand, is being judged according to the standards of a 1.5 spec. OOXML's ISO process has been an order of magnitude more rigorous than ODF's. OOXML 1.0, if approved, will be complete and polished, neither of which can be said for ODF 1.0. If you had called for ODF going through the slow track, then your calls for OOXML to go through slow track might have some weight, but as it is, you're being so inconsistent as to be laughable.

Anonymous
March 05, 2008
The comment has been removed
Anonymous
March 05, 2008
Francis said "Stephane: Do you have any reason to believe that Office 2009 will obsolete OOXML/DIS 29500 (dispositions included?) Presumably Office 2009 will include new functionality." These are not my words. I took a specific example, Custom XML part bindings. Here is the problem. Custom XML part bindings is only implemented in Word 2007. And since ECMA 376 was written AFTER what we now know as Office 2007 reached "feature complete" milestone, we end up with ECMA 376 in which there is no such Custom XML part bindings for spreadsheets and presentations. But Microsoft has sold us Custom XML parts in OOXML, i.e. for all three applications. See what I mean? So, presuming that with two more years they finally managed to add those Custom XML part bindings to all three applications, the consequence is that this will have to be reflected in ECMA 376 changes. My problem with that is :

We've been sold features that do not exist right now
The "standard" is a direct reflection of something that was not finished, and that is the consequence of a single vendor's inability to do things right in due time. So the updates that are coming are less normal updates that follow the update of a standard (such as ODF 1.1 versus ODF 1.0) than poor handling of the subject, presumably for commercial reasons. I suspect Office 2007 was due to ship simultaneously with Windows Vista, back in 2006. So we are here paying for something we should not be bothered with, should it have been properly handled. VML anyone?

Anonymous
March 05, 2008
The comment has been removed
Anonymous
March 05, 2008
@Bruno If OOXML was complete and polished, why is there a need to add 3 new date representation systems just 30 days before the final approval ? Check how much time was spent between ratification of ODF by OASIS and submission to ISO. Then compare to the time between ratification of OOXML by Ecma and submission to ISO. It should become clear which one was rushed. I'm sorry to be rude, but you are a troll, and your post don't deserve to be replied to further.
Anonymous
March 06, 2008
The comment has been removed
Anonymous
March 06, 2008
ISO has published the list of resoluiton of the BRM. Resolution 37 is the resolution that decided on using the form vote as a means to decide on the rest of the outstandting dispositions. The vote result on Resolution 37 29 in favour 0 against 2 abstain So all in favour of this voting method before the vote, but a lot of noise after the vote. Why did those people speaking out so loudly not speak up when this voting method was proposed ? Some have suggested that certain 'disapproval of all disposition' votes on this form were out of principel. But if you first vote in favour of this form vote then it seems more like you tried to win it by disapproving all and then show to be a sore loser afterwards.
Anonymous
March 06, 2008
I see over on Alex Brown's blog that the results of the BRM are publicly available now. There are two
Anonymous
March 06, 2008
I see over on Alex Brown's blog that the results of the BRM are publicly available now. There are
Anonymous
March 06, 2008
The comment has been removed
Anonymous
March 06, 2008
@Luc Bollen ODF 1.0 does not even support basic spreadsheet functionality (among other things), making it unsuitable for government use, but IBM is lobbying governments to mandate exclusive use of that format based on the ISO imprimatur. IBM is, in effect, LYING to these governments when IBM claims that ODF is sufficient for their needs. Are you really applauding that? Rather than constantly trash OOXML, why not look at the flaws and dishonest marketing of your own format of choice, ODF? Is it because you simply refuse to admit that ODF is flawed and being dishonestly lobbied for, or just don't care? If you think OOXML was "rushed", fine, but if you don't have the honesty to admit that ODF was rushed and received much less rigorous review than OOXML has, then you are the troll, hiding behind psuedo-intellectual babble. Too many like you run around pretending that ODF 1.0 is perfect, or nearly so, ignoring that it has huge defficiencies, and two years later, those defficiencies still have not been addressed (ODF 1.1 and 1.2 still haven't been submitted to ISO, probably because this time people will actually bother to look at it (ODF 1.0 was rubberstamped because nobody really cared so nobody examined it). The double standard is quite striking regarding the slack you're giving ODF vs the zero slack you give OOXML.
Anonymous
March 06, 2008
@Bruno -If ODF covers text documents - the majority of all documents - and does not support spreadsheets, then why can't it be used for text documents? Is it to be all-or-nothing? In the wake of the EU judgement of the more open Microsoft over interoperability standards, it makes sense to more carefully scrutinize MS behavior in other areas where interoperability is key. Besides, when ODF gets a majority hold on document format usage, it too will be examined with care.
Anonymous
March 06, 2008
The comment has been removed
Anonymous
March 06, 2008
@Bruno >> ODF 1.1 and 1.2 still haven't been submitted to ISO Gee, I wonder why not? Certainly not because the committee membership is currently stuffed full of Microsoft proxies, ready to vote it down on orders from Redmond. No siree. In fact, they don't even have to vote against it, do they? They just have to sit on their hands and watch it fail by default. Just like they did for months after the first OOXML vote, until somebody poked them with a stick and said "hey, you're actually supposed to do some things here, now that you've signed up". Cheers,

Mike

Anonymous
March 06, 2008
@Bruno (again!) >> ODF 1.0 was rubberstamped because nobody really cared >> so nobody examined it Hmmm... I believe that Microsoft itself was one of the parties that voted in favour of ODF 1.0, as the company never tires of telling us - "hey, we scratched your back, why won't you scratch ours?" Are you saying now that Microsoft didn't read the spec beforehand? Cheers,

Mike

Anonymous
March 07, 2008
Doug Mahugh just posted about a call this afternoon where the U.S. V1 technical committee reviewed the
Anonymous
March 07, 2008
Doug Mahugh just posted about a call this afternoon where the U.S. V1 technical committee reviewed the
Anonymous
March 07, 2008
The comment has been removed
Anonymous
March 08, 2008
The comment has been removed
Anonymous
March 11, 2008
@Mike The pity is that, whatever the result at the end of March, Microsoft has already reached one of his goals: discredit ISO. They perfectly knows that a weaker ISO means a stronger Microsoft. ISO having a strong reputation in defining de jure standards means that de facto "standards" imposed by Microsoft are less highly regarded. Weakening the reputation of ISO clearly benefits Microsoft.
Anonymous
March 12, 2008
The comment has been removed
Anonymous
March 14, 2008
The comment has been removed
Anonymous
March 14, 2008
Mike, OpenXML has improved as part of ISO, but it was never broken. The number of changes indicate that there was room for improvement, but that will always be the case. Do you think ODF was a good refection of an ISO process working? That seemed far more flawed than what you're seeing now with Open XML. -Brian
Anonymous
March 15, 2008
The comment has been removed
Anonymous
March 15, 2008
The comment has been removed
Anonymous
March 15, 2008
The comment has been removed
Anonymous
March 16, 2008
@Mike: What do you define as ballot stuffing? I'd say that lobbying officials and companies to vote against OpenXML is at best morally equivalent to lobbying officials and companies to vote for OpenXML (I think its worse because they are lobbying against a standard that would be in most peoples' interest). Microsoft has publically stated that it has not and will not offer any compensation in return for votes on OpenXML. The unfortunate issue in Switzerland was an exception to this policy that came to light because it was reported by Microsoft itself before any damage could be done to the integrity of the process in Switzerland. Do you have anything else, other than innuendo, to suggest that Microsoft did something unethical? It certainly would be odd for Microsoft to spend so much time on a standardization effort only to leave the review solely to competitors interested in killing the standard regardless of technical merit.
Anonymous
March 16, 2008
@nksigh, >> What do you define as ballot stuffing? There's plenty of examples at: http://www.noooxml.org/irregularities Take your pick. Why not start with Italy, where the committee "suddenly grew from 5 to 83 after Microsoft introduced a lot of its local partners". Is that your idea of "lobbying"? >> The unfortunate issue in Switzerland [Microsoft's >> attempted vote buying] was an exception I've no doubt that somewhere in a dusty cupboard, there's a Microsoft policy book that says "thou shalt not offer compensation in return for votes in any committees". However, a company's publicly stated policies are one thing; its actions on the ground are something else. Sure Microsoft admitted to overstepping the mark in Switzerland, and sure "it was all a big mistake". But really, wasn't that incident just a logical extension of their actions all over the globe? So Microsoft reported the incident themselves. Good on them!! But really, having committed their faux pas via email, they must have known that it would come out eventually. These things always do. The Laws of Damage Limitation say "better to own up first". >> It certainly would be odd for Microsoft to spend >> so much time on a standardization effort only to >> leave the review solely to competitors interested >> in killing the standard regardless of technical >> merit. I rest my case. Microsoft's attitude to standardisation (and to the world in general, for that matter) summed in a single sentence. I don't know if you work for them, and I don't care either. But you've absolutely nailed them here. I'm not even going to begin to explain to you what's wrong with this picture. If you don't get it now, you never will. Cheers,

Mike

Anonymous
March 17, 2008
Mike, Again, both sides are doing what you mention. I don't think there is anything wrong with what IBM is doing, as long as they follow the rules. The same goes for Microsoft. As I've said numerous times, you have to look at both sides. -Brian
Anonymous
March 17, 2008
The comment has been removed
Anonymous
March 17, 2008
Mike, Have you looked at who the 78 new members are? It is my understanding that a large number joined from both camps. -Brian

Partager via

More thoughts on last weeks BRM

Comments

Ressources supplémentaires