Freigeben über

Can I mention that it’s also in ODF?

  • Artikel

I try to keep the discussion on this blog primarily focused on the area I care most about, the technology behind Open XML.

Every so often I've mentioned ODF, especially when discussing the translation and harmonization updates, but in terms of discussing the format itself I've assumed that other folks have more interest in it than me, so I've left it to them to discuss. Surprisingly though, many of the ODF folks would rather discuss Open XML than ODF. I haven't seen a lot of vocal pro-ODF blog posts out there, but I've seen tons of anti-OpenXML posts.

Of course it's entirely possible to be both pro-ODF and pro-OpenXML, like the ODF Editor, Patrick Durusau, for example.

But there's also a camp that identify being pro-ODF with having to attack OpenXML. They don't seem to care that deeply about discussing ODF, just about stopping OpenXML. Those are the folks I refer to as being "anti-OpenXML".

I've noticed a common thread within the anti-OpenXML camp in the past few months (actually they've been doing it longer than that). They claim that a "flaw" in Open XML is totally unacceptable despite similar "flaws" in ODF because "we aren't talking about ODF, we're talking about Open XML, and two wrongs don't make a right."

Basically the anti-OpenXML folks' goal is to constantly keep focusing on any aspect of Open XML they can claim is a flaw, and then try to blow it up into a huge deal (see some of Rob Weir's latest posts as examples of this). This is easy to do of course; it's like one of those trashy entertainment shows reporting on the Oscars, and ripping on everyone's dress. It's easy to tear things down and try to position everything in its worse light, but of course if you try to turn the attention back at them they quickly change the subject. This is why the anti-OpenXML folks are very nervous about the discussion ever turning towards ODF. You see, as anyone who's worked with the spec knows, ODF has flaws just like every other spec, some of them could even be considered to be major. It's still developing into a useable spec with folks like Patrick Durusau leading the way in a constructive and calm manner.

So let me take some of the issues that have been raised about Open XML and show how they apply equally and often more so to ODF. This isn't to denigrate ODF in any way, it's to demonstrate that the anti-OpenXML folks' political games are just that – games that should be left to the politicians. So here goes:

Spreadsheet Dates

Folks have been discussing this one for about a year now; it's about the date format used in SpreadsheetML. In the Ecma responses and even in the BRM, we made a number of changes to make everyone happy. Here is where we are now with dates in SpreadsheetML:

  • There is a new date datetype for cell values, and the only way to store into that datatype is with ISO 8601.
  • For calculations primarily, there is often the need to convert from a date into a serial value or back. For this purpose you need to know the date base, or epoch, and in the ISO version of ODF there are essentially 3 date bases (only one of which is transitional)
  • The leap year bug, and issues around dates before 1900 are now only allowed in transitional conformant files, but if the file is strict it cannot use these.

Let's take a look at ODF now:

  • You can store a date as an xsd date type (which is actually different from ISO 8601 in a few ways including the way to treat the year zero). What many people don't know is that in OpenOffice you can also store a date as a serial number. These two date formats are exactly the same in OpenOffice:
    • <table:table-cell
      office:value-type="date"
      office:value="55"/>
    • <table:table-cell
      office:value-type="date"
      office:date-value="1900-02-25"/>
  • Now, the two values above are considered the exact same date, on one condition, and that is if date-value tag looks exactly like this:
    • <table:null-date
      table:date-value="1900-01-01"/>
    • Here is what the ODF spec says for this element:
      • "The <table:null-date> element specifies the null date. The null date is the date that results in the value "0" if a date value is converted into a numeric value. The null date is specified in the element's table:date-value attribute. Commonly used values are 12/30/1899, 01/01/1900, and 01/01/1904"
  • Of course, the null-date value (essentially the epoch) could be set to anything, and that would change how you interpret that first date I show above. So while the anti-OpenXML folks are claiming that there are too many date bases in Open XML, in ODF you have an infinite number of date bases to deal with.
  • The values set here also affect calculations of course, but that never came up in the ISO review of ODF because as we all know by now there is no definition for spreadsheet calculations/functions. The upcoming draft of OpenFormula though which the OASIS folks are working on does indeed have these same behaviors where you convert a date into a serial value using the epoch before you perform the calculation.

Printer settings

In Open XML, printer settings for all three document types (WordprocessingML; SpreadsheetML; PresentationML) are already fully defined in the standard. Part 4 clause 4.3.1.26 defines a number of relevant printing properties for presentations. Part 4 clause 3.3.1.61 defines page setup properties and 3.3.1.68 defines other print options which affect printing of a spreadsheet. Part 4 clause 2.6.19 defines the section properties of a wordprocessing document and contains many print related settings. So there are a large number of printing properties fully defined in the Open XML specification based on the usage in the existing corpus of legacy documents.

Beyond these print settings however, there is also an option where a specific printer manufacturer can store their own settings with the document. These may include things like whether or not to use a staple, or other more advanced professional printing behaviors (like binding, etc.) that may be specific to that particular printer and the functionality it supports. It is outside of the scope of DIS 29500 to define a generic mechanism for the printing industry to use, but as the Ecma response states, when the industry decides to create a standard for representing these types of printer settings, the spec should be updated to reference that standard.

If you look at ODF on the other hand, no printing properties are defined (zero). Instead it is up to applications to use the generic extensibility mechanism defined in section 2.4. Beyond that no guidance is provided for how to store any printer settings. Because of this, applications like OpenOffice use the extensibility mechanism to add their own set of properties, very similar to what's already fully defined in DIS 29500. For the settings that are printer specific however, they use a binary blob of data as follows:

<config:config-item config:name="PrinterSetup" config:type="base64Binary">

Vgr+/1xcUFJOLUNPUlAxXGIzNi0zMzEzLWEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAWGVyb3ggV29ya0NlbnRyZSBQcm8gMzUgUFMAAAAAAAAWAAEAn AkAAAAAAAAFAFZUAAAkbQAAM1ROVwIACABcAFwAUABSAE4ALQBDAE8Aug BQADEAXABiADMANgAtADMAMwAxADMALQBhAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQQABtwAuAhT/wEAAQABAOoKbwhkAAEADwBYAgEAAwBYAgMA AQBMAGUAdAB0AGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB AAAAAAAAAAEAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUFJ JVuIwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABgAAAAAABAnECcQJwAAECcAAAAAAAAAACgB/AMAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADAAAAAAAAALwEEABcSwMAaEMEAAAAAAAAAAAA AQABAAAAAAAAAAAAAAAAAAAAAAAYwjLhCgAAAAAAAAD/AP8AAAACAAAAA QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgBAABTTVRKAAAAABAAG AFYAGUAcgBvAHgAIABXAG8AcgBrAEMAZQBuAHQAcgBlACAAUAByAG8AIAAzA DUAIABQAFMAAABJbnB1dFNsb3QAKlVzZUZvcm1UcmF5VGFibGUAUGFnZVNp emUATGV0dGVyAFBhZ2VSZWdpb24AAExlYWRpbmdFZGdlAABSZXNvbHV0aW9 uADYwMHg2MDBkcGkARHVwbGV4AER1cGxleFR1bWJsZQBDb2xsYXRlAFRydWU AU3RhcGxlTG9jYXRpb24AU2luZ2xlAFhyeElucHV0U2xvdABUcnVlAFJvdGF0aW9u AFRydWUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAvAQAADlYUlgCAAAATU9DWAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAARAAAABYBAAAAABcD0AEAABgD6AEAAB wCbwgAAB0C6goAABsBAAAAABIBAAAAAAEBAQAAAHgBAgAAAGwBAQAAALM BAAAAAGUBAQAAAHcDAAIAAJEBAQAAAGkBAAAAAGoBFQAAAH8BAAAAAG8 BAgAAAHABAAAAAHEBAQAAAHIBAQAAAJIBAAAAAJMBAAAAAJQBAQAAAGYB AAAAAJcBAAAAAKEBAAAAAJgBAAAAAKIBAAAAAJkBAAAAAKMBAAAAAJYBAQ AAAKABAQAAANECbwgAANIC6goAANsBAAAAAOECbwgAAOIC6goAAOMBAAA AAOoDGgIAAOsDXAIAANYDngIAANcD4AIAALoDIgMAALsDZAMAAM4CBQAAAN ACBQAAABkBAQAAAGsBAwAAAG0BAAAAAA0BAAAAAIkBAAAAABQBAAAAAB UBAQAAAAIBAAAAAAMBAAAAAAQBAgAAAA8BAAAAABEBAAAAABABAAAAAI wBAAAAAIoBAAAAAIsBAAAAAHoDpgMAAHwCAAAAAH0CAAAAACARAAAAAD MRAAAAABQAAAAwAAAAAAAAAAAAAAAAAAAAAAAAABQAAAAwAAAAAAA AAAAAAAAAAAAAAAAAABYAAAAyADUAMgA1AAAAAAAAAAAAAAAAAAAAP gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPgAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgEAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

</config:config-item>

Clearly the approach defined in Open XML is far more interoperable.

Password Hashing and Encryption

We had a bunch of people complain that the hashing algorithm for passwords in Open XML was not clear enough in terms of the documentation. We completely cleared that up between the responses and the BRM to the point where anyone can recreate the same hash, and there is a very robust and flexible way of specifying which has algorithm you use to stay up to date.

What does ODF do here? Well, here is what is in the spec that went through ISO:

To avoid saving the password directly into the XML file, only a hash value of the password is stored.

Great, it's hashed! But how do you create the hash? If I'm writing an application, how do I implement it to work with other applications?

Allows binary formats

There have been complaints that binary formats are allowed in OpenXML. We cleared that up during the review process leading up to the BRM.

Let's look at ODF though:

Section 2.4.2 Base Settings:

Allows for a config:type=base64Binary

Section 9.3 Frames

Frames can contain:

  • Text boxes
  • Objects represented either in the OpenDocument format or in a object specific binary format

…

Section 9.3.2 Image

The image data is contained in the <draw:image> element. The <draw:image> then element contains an <office:binary-data> element that contains the image data in BASE64 encoding.

…

If required, the draw:filter-name attribute can represent the filter name of the image. This attribute contains the internal filter name that the office application software used to load the graphic.

 

[Brian Note: No clue what the list of filter-names are, where they come from, how you structure them, or how you are supposed to get interoperability from this]

Section 9.3.3 Objects

A document in OpenDocument format can contain two types of objects, as follows:

…

  • Objects that do not have an XML representation. These objects only have a binary representation, An example for this kind of objects OLE objects (see [OLE]).

…

The <draw:object-ole> element represents objects that only have a binary representation.

Section 9.3.5 Plugins

A plugin is a binary object that is plugged into a document to represent a media-type that usually is not handled natively by office application software. Plugins are represented by the <draw:plugin> element

Weak Conformance?

Some folks have tried to claim that Open XML's conformance is weak. The conformance of Open XML is pretty well defined, and is set up to allow for applications to come along and only support a particular piece of the schema without having to implement the rest (imagine a server app that only operates on the data in a spreadsheet but doesn't deal with the formatting, charting, etc.). We also have conformance classes, so that a government for example could say it wants to buy an application that is conformant only to the strict schema, and not the transitional. This is all set up in the conformance clause.

What does the ODF conformance say?:

There are no rules regarding the elements and attributes that actually have to be supported by conforming applications, except that applications should not use foreign elements and attributes for features defined in the OpenDocument schema.

Reuse of existing standards

ODF claims to reuse a number of existing standards, but it's never quite that clean. Jesper has some great examples of a couple odd cases:

Calendar Definitions

There were a number of complaints claiming the Open XML only defined a sub set of the calendars fully and needed to define them all. This was done, and now every calendar definition has a normative definition.

Here's an example of some of the calendars defined and allowed by Open XML:

Enumeration Value 

Description

gregorian (Gregorian)

Specifies that the Gregorian calendar (ISO 8601, §3.2.1) shall be used.

 

This calendar should be localized into the appropriate language. 

gregorianXlitEnglish (Gregorian transliterated English)

Specifies that the Gregorian calendar (ISO 8601, §3.2.1) shall be used.

 

The values for this calendar should be the representation of the English strings in the corresponding Arabic characters (the Arabic transliteration of the English for the Gregorian calendar). 

gregorianXlitFrench (Gregorian transliterated French)

Specifies that the Gregorian calendar (ISO 8601, §3.2.1) shall be used.

 

The values for this calendar should be the representation of the French strings in the corresponding Arabic characters (the Arabic transliteration of the French for the Gregorian calendar).

hebrew (Hebrew)

Specifies that the Hebrew lunar calendar, as described by the Gauss formula for Passover (Har'El 2005) and The Complete Restatement of Oral Law (Mishneh Torah) (Maimon n.d.), shall be used.

hijri (Hijri)

Specifies that the Hijri lunar calendar, as described by the Kingdom of Saudi Arabia, Ministry of Islamic Affairs, Endowments, Da'wah and Guidance (Kingdom of Saudi Arabia, Ministry of Islamic Affairs, Endowments, Da'wah and Guidance n.d.), shall be used.

japan (Japanese Emperor Era)

Specifies that the Japanese Emperor Era calendar, as described by Japanese Industrial Standard JIS X 0301, shall be used. 

korea (Korean Tangun Era)

Specifies that the Korean Tangun Era calendar, as described by Korean Law Enactment No. 4 (Korean Law Enactment No. 4 1961), shall be used.

saka (Saka Era)

Specifies that the Saka Era calendar, as described by the Calendar Reform Committee of India, as part of the Indian Ephemeris and Nautical Almanac (Calendar Reform Committee 1957), shall be used.

taiwan (Taiwan)

Specifies that the Taiwanese calendar, as defined by the Chinese National Standard CNS 7648 (Bureau of Standards, Metrology and Inspection of the Ministry of Economic Affairs n.d.), shall be used.

thai (Thai)

Specifies that the Thai calendar, as defined by the Royal Decree of H.M. King Vajiravudh (Rama VI) in Royal Gazette B. E. 2456 (1913 A.D.) and by the decree of Prime Minister Phibunsongkhram (1941 A.D.) to start the year on the Gregorian January 1 and to map year zero to Gregorian year 543 B.C., shall be used.

 

What does ODF do here?

number:calendar attribute (section 14.7.11)

The attribute may have the values gregorian, gengou, ROC, hanja_yoil, hanja, hijri, jewish, buddhist or an arbitrary string value. If this attribute is not specified, the default calendar system is used.

Yup, that's it.

Fast Track Process

While the anti-OpenXML folks are trying to claim the fast track process is flawed, I would say the result of the fast track process is an even better spec that what we had when we started. Remember that the standard from Ecma (Ecma 376) has already been implemented by a ton of other companies, so even if it had room for improvement, it was already serving its purpose.

ODF went through a similar process, and it's fair to say that it didn't receive nearly the same level of attention. There were some fair points raised by national bodies though, and I thought it would be fun to look at some of the comments ODF received: https://blogs.msdn.com/brian_jones/archive/2008/03/20/out-of-time.aspx

Accessibility

Obviously there was already a lot of great accessibility functionality built into Open XML, and as a result of the ISO process it's become even richer (thanks to some great feedback from Canada and New Zealand).

ODF created an Accessibility sub-committee after ISO approval and then added an accessibility annex to their version 1.1, which has never been brought to ISO.

Closing

I'll close by repeating that I don't intend this post to be anti-ODF in anyway. Instead I'm pointing out that there will always be designs that folks disagree with, and areas for improvement in a standard. If we waited for it all to be perfect, then we'd find the industry had moved on to something else. It's important to get a stable spec out there for folks to start building on. We can then see how it's used, and make improvements/corrections from there. This is what you see in ODF, and we'll see the same thing with Open XML.

-Brian

Comments

  • Anonymous
    March 25, 2008
    Brian, This was a very astute observation, I like it: "It's like one of those trashy entertainment shows reporting on the Oscars, and ripping on everyone's dress. " Miguel

  • Anonymous
    March 25, 2008
    RE:  "Remember that the standard from Ecma (Ecma 376) has already been implemented by a ton of other companies, so even if it had room for improvement, it was already serving its purpose." Could you please define "implemented" for your customers? By "implemented", do you mean that a "ton of other companies" have already deployed Office 2007, and are now saving their office files to the new formats?   If those "ton of other companies" are anything like the company I work for, the only reason they would start "implementing" (i.e. "saving") office files to the new formats, is because they have no choice if they want to be able to use all of the new Office 2007 features they PAID for when they bought the product.    Bibliography/Citations in Word and the expanded grid size in Excel are just 2 examples of many.  

  • Anonymous
    March 25, 2008
    @funnybroad Implentation of a specification and deployment of an application are different things.  Are you in IT?

  • Anonymous
    March 25, 2008
    ... but I'm not a developer.  I'm a Software Deployment Project Manager. I'd be grateful if you could explain what is meant by "implemented" and "purpose" in this excerpt:  "has already been implemented by a ton of other companies, so even if it had room for improvement, it was already serving its purpose."   Examples and numbers would be wonderful!

  • Anonymous
    March 25, 2008
    The comment has been removed

  • Anonymous
    March 25, 2008
    The conclusion here is that they are both flawed. Why should ISO be standardising either of them? And why make matters worse by standardising a second one? Finally, why did you not provide feedback during the ODF design phase.  

  • Anonymous
    March 25, 2008
    Pour faire référence à mon précédent post , voici un petit compte rendu rapide de cette journée, ou plutôt

  • Anonymous
    March 26, 2008
    Now that we're getting down to the final days of the DIS29500 standards process, it's interesting to

  • Anonymous
    March 26, 2008
    The comment has been removed

  • Anonymous
    March 26, 2008
    The comment has been removed

  • Anonymous
    March 26, 2008
    Jake, It is the OOXML standard itself that defines what is an "implementation".  By that definition, all what I talked about are implementations.

  • Anonymous
    March 26, 2008
    Jake, Further to what I wrote... I think you do have a valid point in that many people assume that an OOXML "implementation" means an Office Suite or tool kit that implements all of the capabilties of the standard.  The opponents of OOXML have seized upon this confusion to claim that there are no implementations of OOXML. I would be happier if we were all to use a phrase like "application that uses OOXML".   P.S.  It's not just the OOXML SDK that currently does all the low-level stuff.  All the "implementations" I mentioned use low-level stuff so far, because things like the toolkits aren't fully capable yet.  

  • Anonymous
    March 26, 2008
    Ian...  THANKS for that clarification.  I agree with using the phrase "application that uses OOXML" instead of "OOXML implementations". That would clear up a LOT of confusion for us I.T.-but-not-developer-types who are trying to make decisions related to the new file formats as we plan our Office 2007 deployments (i.e. should we set the default save/as format to the legacy formats until a certain percentage of our users are migrated?)   I can't recite any specific Microsoft sources right now, but somewhere along the way, I got the impression that "implementations" were gauged by counting/estimating the number of files already in existence in the new OOXML format.    

  • Anonymous
    March 26, 2008
    The comment has been removed

  • Anonymous
    March 26, 2008
    Megaloman: By that logic, ODF should never have been standardized, since we already have HTML and PDF. Different standards do different things. By your logic, we should all be using X.400 for our email, since it predated POP3 and IMAP (and is an ISO standard to boot). POP3 and IMAP4 each do different things and server separate constituencies, even though they're both Mail User Agent (MUA)protocols.

  • Anonymous
    March 26, 2008
    Dan Matei, președintele CT210 a anunțat rezultatul votului de marți : Pro: 15 Contra: 6 Abtinere: 5 Astfel,

  • Anonymous
    March 26, 2008
    "Different standards do different things." Yep, that's why consumers love choise: DVD-R vs DVD+R or Blu-Ray vs HD-DVD. Those Microsoft customers who own an XBox360 and a HD-DVD drive must be delighted nowadays after they utilized their precious consumer choices and chose HD-DVD.

  • Anonymous
    March 26, 2008
    The comment has been removed

  • Anonymous
    March 26, 2008
    Anti-Open XML lobbyists have long been crying foul on some of the flaws in the specification. Two main

  • Anonymous
    March 26, 2008
    The comment has been removed

  • Anonymous
    March 27, 2008
    CGR : 3) But MS is a monopoly in the market. Which is its measure of success, american way. Never heard of unofficial moves ? There is always a way to lure the customers to use what you want, not what they want. There is a loooong history of that....

  • Anonymous
    March 27, 2008
    LarryOsterman: sure, different standards for different things - I agree, but Open XML is actually for the same as ODF, isn't it? and following your answer - HTML and PDF were designed for different purposes, ODF and Open XML are designed to do exactly the same. or maybe you are actually right. ODF was designed to be an open standard, Open XML is designed to keep Microsoft Office Suite on the market. I am seeing many things done in wrong way here: Office 2007 implements something like Open XML, but it's not actually Open XML. now other developers will be able to create implementation of Open XML which will be incompatible with Office 2007 default format... and Office 2007 users have no way to save documents in a real Open XML format... it sounds like Microsoft is trying to make everything complicated, so people will be actually forced to use its proprietary closed and Open XML incompatible format. Wouldn't be easier and better for microsoft just to adopt Open Document Format and make Office suite the best app which supports and implements ODF? Customers love choice and freedom - they are happy to choose between different applications, but they are really unhappy to deal with multiple and incompatible formats and standards.

  • Anonymous
    March 27, 2008
    Megaloman: ODF, OOXML, HTML and PDF are ALL  document representation formats.  So by your logic, they're ALL the same. Why didn't the ODF people use an existing standard for their documentation format?  The answer is that there wasn't a good fit between thei requirements of OO.o and the previously existing formats.  Similarly (as I understand it from reading the various blogs - I'm not an area expert) there isn't a good fit between ODF and Microsoft Office (and as Brian has said many times, both formats were developed in parallel).  

  • Anonymous
    March 27, 2008
    First (to Megaloman): ODF, OOXML - Editable Office documents (same stuff) PDF - Non editable documents (as an electronic paper). Microsoft will try to break this too, with XPS that is on his way to Fast-Track !!! HTML - Web-based documents. They are different, ok ? Second: The argument that OpenXML is now a better standard doesn't means that it is good to e approved as an international standard ? (I was at the BRM and I saw the whole thing... come on). Third (and last, I promise): Would you fly on a not-so-good airplane ? Cheers from Brazil, and our NO means really NO !!! Jomar PS.: Good to see that you already started studying ODF... very good and cheers again :)

  • Anonymous
    March 27, 2008
    to LarryOsterman: “Megaloman: ODF, OOXML, HTML and PDF are ALL  document representation formats.  So by your logic, they're ALL the same.” as Jomar pointed it out, they are not the same. If you want to make printable document, you won't do that in HTML, will you? “Why didn't the ODF people use an existing standard for their documentation format?  The answer is that there wasn't a good fit between thei requirements of OO.o and the previously existing formats.  Similarly (as I understand it from reading the various blogs - I'm not an area expert) there isn't a good fit between ODF and Microsoft Office (and as Brian has said many times, both formats were developed in parallel).” I didn't mention OO.o - OO.o is not the only one implementation of ODF, there are other implementations, I have a choice. Also my choice is to save all my documents in Open Document Format which is already an ISO standard. If I get any office document, I am simply and kindly asking sender to send me a document in ISO standard document format such as ODF or PDF. Why is that? I don't even know what the *.docx is - why should I bother? The main reason, that ODF does not fit in Office is a control - Microsoft does not have a control over ODF and that's why Microsoft does not want to implement native support of ODF in Office Suite. I am sure that no one form Microsoft would admit that, but you don't have to be a rocket scientist to work it out. Of course these customers who are depend on microsoft products they are not going to switch to ODF... I am trying to understand why Microsoft is creating another standards? Any good reasons? I am reading about it and I cannot find any good and reasonable reason for second standard. It's like having an Motorway A and Motorway B - now Motorway A can be used by cars made by company C, but Motorway B can be used by cars made by other companies. Shouldn't there be a one Motorway type which can be used by any car?

  • Anonymous
    March 27, 2008
    To Megaloman: "I am trying to understand why Microsoft is creating another standards? Any good reasons?" The real and "huge good reason" (at least to Microsoft) can be found here: http://www.openmalaysiablog.com/2007/09/microsoft-tech-.html This is from Doug Mahugh, the former OOXML Evangelist (and also a very good person... true).

  • Anonymous
    March 27, 2008
    The comment has been removed

  • Anonymous
    March 27, 2008
    OK... Very good... And Santa Claus and Eastern Bunny are also working with you ? Please, you really want to discuss the NAME of the specs ??? Already forgot the issues with the name "Office Open XML" placed (and completely ignored) by NBs ? (just to refresh, Response 5... ok ?) Do you have an idea about the amount of times that I've had to explain to people that "Office Open XML" wasn't the Open Office default format and that Microsoft isn't supporting Open Office (including here several CIOs and a dozen of journalists)? Even a Microsoft page (health care solutions) has that error (calling it "Open Office XML"), but it was pointed on several NBs and you guys have changed the page (no problem, the ECMA responses document this "mistake" appears - responses 374 and 976 - and this you cannot fix !!!). It is simple Brian: If you really care about Open Formats and user choice, support ODF on Microsoft Office, join OASIS TC and let's work together. This will really offer more choices to users (and also show some respect to the market... you guys really need to show some respect anytime). If you think that Microsoft Office is really the best on the market (even on a commodity based market) what are you guys worried about ? A finally, don't come with that LEGACY SUPPORT fallacy... "NO LEGACY MAPPING, NO TECHNICAL PROVE = MARKETING"... The same for "internal development of OpenXML since 1904..."... come on... Regards, Jomar

  • Anonymous
    March 27, 2008
    Jomar, I have to admit I'm more friendly with the Western Bunny than with his counter-part. Take a few breaths my friend... it's ok. :-) I think you should focus on the rest of my post and not stick to just the issue around the name of the spec (which I just mentioned off-hand at the end). I think it's pretty obvious why ODF wouldn't have worked, and that again (I don't know how many times I have to repeat this) we didn't pick one over the other. Open XML was initially designed by us, and ODF was initially designed by SUN. On the current ODF committee 8 our of 11 voting members either work for Sun or IBM. I think the right place to do any type of maintenance or improvements to either spec is within ISO. We're fully committed to that, and I hope the ODF folks eventually bring things back there rather than keeping them with OASIS. In terms of legacy mapping, we had numerous experts on the legacy binary formats from Apple, Gnumeric, Novel (OpenOffice), and Microsoft Office. Even some of the consumers like Barclay's capital had project that consumed the binary formats. So there was a ton of expertise, and that's how we were able to ensure the Open XML formats represented the necessary information. The goal wasn't to build a mapping, it was to build a new format. -Brian

  • Anonymous
    March 27, 2008
    The comment has been removed

  • Anonymous
    March 27, 2008
    The comment has been removed

  • Anonymous
    March 27, 2008
    Brian: you still haven't answered my question - where is that good reason to have another standard? also, I don't think adoption of ODF would confuse customers - I have heard from customers, that they would be happy to have native ODF support in Microsoft Office Suite, but that's not going to happen. just to let you know - in my humble opinion MS Office is the best office suite I have ever seen, but there is one problem - it does not support ODF and it does not support Linux. But I do believe that two incompatible standards for the same purpose will confuse customers. For customers it will became a nightmare, when they discover, that their MS Office does not save automatically files in strict Open XML, but something which is similar to Open XML. Do you get my point? to you read my posts? I can clearly see, that you're not. You don't read other people posts too, you don't respond to them, you're just repeating your mantra - but... is it really yours? Jamal: Thanks for links, I will read them.

  • Anonymous
    March 27, 2008
    el es: are you sure there are so many ways to lure a customer tu buy what you want and not what he wants, but that speaks tons about the wits of that customer! Would you let some bright salesmen convince you to buy a tractor when you need a bike? On the other hand remember that MS Office installed base is huge compared, so enforcing OOXML to the customers would't be that much of a problem! Why standardize? Because MS wants broader acceptance of this format as well as community involvement in its development.

  • Anonymous
    March 28, 2008
    @Megaloman You are clearly not reading Brian's posts as he has answered your question succinctly.  

  • Anonymous
    March 28, 2008
    The comment has been removed

  • Anonymous
    March 28, 2008
    With respect to the password hashing algorithm, it's documented in section 17.7.6 of the ODF 1.1 spec. That said, it's fundamentally flawed in several respects. For example, the spec requires an iteration count of 1024, which is 50x less than what OOXML uses by default. Worse yet, they do not allow in the spec the iteration count to be anything other than 1024. Further, there is only support for SHA-1, and doesn't allow any of the SHA-2 algorithms. There are other significant flaws in ODF encryption, but I'll detail that on my own blog at some later date.

  • Anonymous
    March 29, 2008
    Cool !!! Now David is also studying ODF !!! This MUST means something !!! []'s Jomar

  • Anonymous
    April 16, 2008
    When you tell a lie often enough, it takes on a patina of truth each time it is uttered, and after a

  • Anonymous
    April 16, 2008
    When you tell a lie often enough, it takes on a patina of truth each time it is uttered, and after a