I just got off a 3-hour call with my colleagues on the V1 technical committee, in which I and the other members of the US delegation to the BRM presented our thoughts on what happened at the BRM. Then we all voted on what to recommend to the INCITS Executive Board for the final US position on DIS 29500.
The final outcome: we are recommending that the US maintain its Approve position on DIS 29500. The next step will be for the INCITS Executive Board to conduct a letter ballot to approve this result.
After all the hard work in V1 going back to the beginning of last year, it's great to have finished up our review of DIS 29500 on a positive note. I think the interests of the United States have been well served by the process, and the spec is much better now than when we started.
More details later. For now, I'm looking forward to a weekend at home!
I don't think anyone who has actually tried to implement ODF without reusing the OOo codebase will agree with you on the tightness of the ODF standard as specified in the ISO spec.
It leaves as app-defined several elements that would be of interest to interoperability and it mishmashes several namespaces together when it comes to drawing (it is not actually SVG-based to the point where you cannot drop in an SVG reader to handle the drawing elements automatically... the same tag names are used but the meanings change slightly, according to Jesper Lund Stocholm, a BRM delegate who seems to be implementing both standards).
ODF is insufficient for todays MS Office format. You might be able to represent the same shapes graphically, but retaining editable representations of Office features was not on the cards for ODF 1.0, 1.1, or 1.2. Maybe it will end up happening for ODF 2.0.. maybe not. Adding features to a format is a lot harder than removing them, so I think it would be wiser to start the next grand unification format from Open XML and whittle it down using profiles and extensibility points to be as clean as ODF.
Regardless of what happens at ISO, people in the open source community and the vendor community will have to implement Open XML, so it's not like anyone is doing less work by starting on ODF.
<blockquote>Fortunately for the rest of the world, not everyone subscribes to your view that "first" to standardize precludes other choices.</blockquote>
It does proclude other choices when all they offer is an obfuscated, bloatier version of the first.
Lucky Microsoft didn't try pushing a crippled TCP/IP clone through ISO, or we <em>really wouldn't</em> be able to communicate on the Web.
[quote]I do not, however, think that anyone could make a solid case for the fact that OOXML is a better standard than ODF. [/quote]
There are areas where OOXML is a lot better than ODF. If those areas matter to you then there is a solid enouhg case for calling OOXML a better standard than ODF.
If for instance you are looking at applying the format for business integration purposes using custom data then surely you would take OOXML over ODF.
If you look at the OPC packaging of OOXML then that is superieur to ODF's packging.
If you you look at the DrawingML markup than the chaotic OOo draw based shambles that is in ODF (aka 'the non SVG compatible format') is definitly not better.
The current conformance clause of ODF is total joke. I have no idea how that passed trough ISO.
In addition to that the maintenance regime with OASIS having full control and ISO with no influence on the ODF format makes ISO members very unhappy.
For instance OASIS has not submitted any 1.1 version to ISO because it could not afford to have the standard scrutunized in a standards proces side by side with OOXML because it would not have passed so easy again again without similar major changes as are applied to OOXML.
Several of those "independent" projects have also implemented Open XML (Gnumeric, Novell Open Office).
The example illustrates the point that "first to standardize" should not preclude other choices. If you think that one solution is superior or better meets your needs then that is your choice.
I hope that you agree that others should have the same freedom to choose.
I'll call your Metric / American Standard, and raise you CORBA / web services. :-)
Doug Mahugh's blogged that the US V1 Technical Committee recommended approval of DIS 29500 (Open XML)
Doug Mahugh blogged that the US V1 Technical Committee recommended approval of DIS 29500 (Open XML) to
Interesting points. I still think that ODF is the far better standard, and that introducing MSOOXML into the mix is like trying to claim that CORBA is the way forward when we already have web services.
Oh, among the independent implementations of ODF, I forgot Koffice.
Can you give me an idea of exactly how much of MSOOXML Gnumeric and Open Office have managed to implement? How much of it will run on something other than MS Windows? My impression is that the answer to both is "not much".
I think that ODF is the far better standard. I think you'd agree that if TCP/IP had been standardised before OSI, then the backers of OSI would've looked pretty ridiculous for trying to foist their ugly baby on the world. I submit that MS look the same trying to ram MSOOXML home. There's no way in which MSOOXML is a better spec than ODF. More importantly, as this is the special case of standardised XML, there's no reason that ODF cannot encompass the requirements MS might have... No matter how you look at it, there's tremendous cost to the marketplace for having 2 standards. It is always undesirable.
The late coming standard must demonstrate itself to be inherently superior to the earlier standard for there to be any possible justification for two. MSOOXML is *not* superior to ODF, except for the fact that ISO or not, MS will continue to be able to control it, thereby protecting their monopoly marketshare and retaining those clients who need to tick the "open standard file format" box.
Don't you think it's a bit rich how MS employees insist on referring to the MSOOXML format as "OpenXML" when Ecma have passed stewardship of the format back to MS? It makes me quite sick to see how badly this process has been gamed for MS's commercial interest.
Doug Mahugh - relayé par Brian Jones - confirme dans son post que le National Body américain, l'INCITS,
The discussion in the comments here is a good one, to my mind it is highlighting why the choice of something like a document format has to be a market decision, not a technical or an ideological one.
"I've read the changes approved in Geneva (and I was there), and I've read nearly all of Ecma's proposed dispositions that were accepted."
So, at the BRM, did you vote in favor of Ecma dispositions that you hadn't read? I wasn't there, of course, but I tend to feel uncomfortable voting for things I haven't read.
"I think the changes are improvements for the most part."
Are some of them simply neutral, or do you think that some of them make the proposed standard worse?
Given the huge number of changes that have been made at the very last minute - and the number of people at the BRM who felt unhappy that they didn't have the opportunity to have important issues heard, I'm surprised at the push from Microsoft to keep moving forward in this manner.
I hear people from Microsoft and Ecma arguing that the standard should be approved as it is now and that the remaining issues should be dealt with during maintenance.
This really makes no sense to me. I thought the point of an approved standard was that it was something ready to be implemented. If there are known, outstanding issues that should be dealt with, and the issue is one of time, why not delay the ratification of the standard until the issues have been dealt with?
As it stands, your recommendation seems to be, "Approve this standard, don't worry about the problems we didn't have time to fix, wait for rev2 and it'll be better."
If the standard really is good enough as-is, then you guys need to stop telling people to not worry and wait for maintenance to deal with the rest of the problems.
If the problems that are outstanding are actually relevant and important, then it's a serious mistake to knowing approve a standard with mistakes for some strange sort of expediency. A flawed and about-to-be-fixed standard isn't useful; I can look at the beta version of the standard now. Releasing the beta and calling it a 1.0 is misleading.
The whole point of a document format as an officially recognized standard is that it is well documented, with clear and complete information that is consistent. The specification as initially proposed by Microsoft was not of appropriate quality for a standards document - it was, rather, a description of how Microsoft had chosen to implement a file format. Many parts of the spec looked to be done a certain way because that's what a software developer thought was convenient, rather than something that was intentionally designed and considered as the "right way" to do something.
Given the incredible shortage of time at the BRM, wouldn't it be better to slow down and at least give the people who wanted to be heard fully at the BRM the opportunity to be fully heard? I find it very difficult to resolve the conflict between the very positive sounding picture you paint here, and the fact that people left the meeting unhappy that they didn't even have a chance to get their viewpoints properly heard.
“I wish my neighbor's cow would die," Je trouve ce nouveau post de Patrick Durusau particulièrement pertinent.
There is many Arabic issue in OOXML (including mistakes in the specs). For example the use of different notations for the HINDIARABIC switch argument and the hindiNumbers ST_NumberFormat enumeration value is not clear.
Also the use of HINDIARABIC switch argument seems is for another type of digits not Arabic-Indic digits.
and many others. This proposal didn't have a chance for careful review due to iso fast track very limited period.
gnumeric, novell: yes, they at Novell support Open XML because they believe in the format. A belief in the format that is documented by contractual obligations and hard cash from Microsoft.
No market player implements the format independently! (*)
The "Open XML community" is a Potemkin village of hired cheerleaders.
(*) Oh yes, IBM lets you parse the XML with XML editors, what an "implementation" of the format.
Hi Doug, I would appreciate a set of links to INCITS and ANSI that provide the bylaws, principles, and guidelines that provide the governance and decision criteria used by V1 and the INCITS board when voting on ISO standards proposals on behalf of all citizens of the USA.
Thanks for all the feedback, everyone. In no particular order ...
Patrick Durusau, the chair of V1, has posted his thoughts on the outcome of Friday's meeting here: http://www.durusau.net/publications/russianpeasant.pdf
@krp, your opinion and lack of supporting facts is duly noted.
@Conrad, ditto. (Sorry, a vague reference to things that "aren't properly documented" isn't the same as referring to specific text in DIS 29500. Section #? Specific quote from the DIS?)
@Dave, regarding the name, I use the name that appears on the cover of DIS 29500, less "Office" which feels redundant to me. Your suggestion, on the other hand, is a fabrication used by various lobbying groups that has never been used by ISO/IEC, ITTF, Ecma, or any other organization officially involved in the standards process. I'm comfortable with letting others reach their own conclusion on which of those approaches constitutes taking "unwarranted liberties" with the name.
@Tom, I don't know where those bylines are so can't help on that one. I'd recommend you ask INCITS or ANSI for such information. For what it's worth, nobody involved has suggested that any rules have not been followed properly, including those who have consistently voted against DIS 29500. The chair of V1 specifically asked whether anyone had concerns about voting procedure at the end of yesterday's call; none were raised.
> So, at the BRM, did you vote in favor of Ecma dispositions that you hadn't read? I wasn't there, of course, but I tend to feel uncomfortable voting for things I haven't read.
Me too, and that's why I recommended that the US take an "abstain" position on the comments we had not reviewed within V1. As of Thursday afternoon we had 100% consensus within the US delegation that "abstain" was the only reasonable position to take, but early Friday morning I found that several members of the US delegation had decided overnight to recommend "Disapprove" instead. You might ask some of them why they chose that position, or share with them your discomfort on the US taking a position on things we haven't read.
> Are some of them [accepted dispositions] simply neutral, or do you think that some of them make the proposed standard worse?
Some are neutral. I know of no disposition that was approved at the BRM which makes the standard "worse" in any objective sense, and I've found the lack of specificity in complaints about the BRM results rather interesting.
As for your comments about whether it would be "better to slow down" at the BRM, I personally had no say in the process for the BRM. But I think Alex Brown an Gabriel Barta did a good job of maximizing our collective productivity under the circumstances, and most people who were there seem to agree with that perspective.