decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
More National Bodies' Comments on MSOOXML That the February Meeting Won't Allow To Be Addressed
Wednesday, December 12 2007 @ 04:15 PM EST

Here are some more comments listed on ISO-Vote.org from the National Bodies' technical committees that won't be allowed to be discussed at the ballot resolution meeting on MSOOXML in February.

I'll just keep telling you about this, little by little, so you know how huge this glossing over actually appears to be. My personal question is, if these comments can't be addressed in February, who will address them and when? No one? Not ever?

If that is really the answer, and a country's only recourse is to vote No, then why even solicit comments in the first place? And if the only comments that will be addressed in February are those provided by Ecma, why bother meeting? Just send us a memo on what you decide, why don't you?

I think it's obvious from the enormous number of comments that were filed from all over the world that there are serious and substantive questions about the MSOOXML proposal. And unlike most standards, this one matters to people. Common people. Folks like me, who want to send a document to my mom and have her be able to read it, even though we use different operating systems. Is that too much to ask?

The whole world knows why it can't happen, if only from watching the EU Commission's decisions in the antitrust action against Microsoft. Microsoft doesn't want to free up those Windows-using people they have inside their castle. XML threatens to free everyone, and so they would like to speak a dialect of XML, just as they did with HTML, except worse, in that the wish to rely on binary blobs that no one can understand but Microsoft. Now, that didn't much matter to me, until now. I used to think that folks that use Microsoft deserved to do penance inside the castle for choosing that software. And as long as *I* didn't have to move in, I didn't care what others did.

But we are talking now about interoperability. Microsoft representatives in the Netherlands are reportedly telling the government there that the converter that Microsoft itself is paying to have written doesn't work. None of them do, he says. He says that this is a good reason to use Office 2007. I think it's a good reason to ask why Microsoft won't let anyone be truly interoperable with them unless they pay them. And that is what a standard is supposed to prevent.

I know. No money up front. But also no true interoperability. Now, some US Microsoft spokesmen are claiming that this or that company has this or that motives for backing ODF. But I'm not a company, and I don't work for any of them. But I have a dog in this fight. I want to be able to send my mom a document and have her able to read it, add to it, and send it back to me and have me be able to read it too. Any standard that Microsoft proposes that can't do that is not a standard. And there is no equivalency to ODF. The road block is the same. Microsoft.

So, as promised, here are some comments that apparently will be considered "out of order" in February:

Australia:

Where there are multiple standards in the same space, they should clearly indicate their different application area. Some reviewers report the name causes confusion.

Some reviewers report that it is important not to differentiate the goals, development method and scope of DIS 29500 Office Open XML with that of IS 26300 ODF in particular. The current name “Office Open XML” is confusing, with ISO Open Document Format (ODF), ISO Office Document Architecture (ODA) and the many various products, notable “Open Office”. Public usage has evolved into “OOXML” and “Open XML” as shorthands.

Furthermore, the name may appear to indicate a (non-standard) dialect of XML rather than a use of XML, which would be regrettable.

However, because “Office Open XML” is the title of Ecma 376 and in products, it is not suitable to change the name of the technology. A change in the name of the proposed Standard will suffice.

Brazil:

It is desired to have improved interoperability among other ISO document standards.

Canada:

Further, Canada makes the following recommendations:

1.Convert this standard to a multi part standard, which would mean the reversion of DIS 29500 to an acceptable level of review within the ISO/IEC JTC 1 development process,

2.If a revision is undertaken, address harmonization, insofar as possible, with other ISO/IEC standards, or where ISO/IEC standards do not exist other referencable specifications....

The name "Office Open XML" is often mistakenly called 'Open Office XML” implying a connection to the OpenOffice project which does not exist. This naming confusion has been documented and has occurred numerous times, including by analysts and even in Microsoft press releases and blogs. Since “Open Office” is the pre-existing name, by 6 years, Ecma should choose a new name, less apt to continue this confusion.

Chile:
Introduction explicitly says that OOXML objective is to be "fully compatible with the large existing investments in Microsoft Office documents". Standards should not be built to be compatible with an existing software; it's exaclty the other way.


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )