Can I mention that it’s also in ODF?


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: http://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 (39)

  1. Miguel de Icaza says:

    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

  2. funnybroad says:

    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.  

  3. Andrew says:

    @funnybroad

    Implentation of a specification and deployment of an application are different things.  Are you in IT?

  4. funnybroad says:

    … 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!

  5. Mike Brown says:

    @Brian,

    >> Can I mention that it’s also in ODF?

    It’s your blog, Brian.  You can mention whatever you like!

    >> many of the ODF folks would rather discuss

    >> Open XML than ODF

    Well, it just so happens that OOXML is the spec that’s about to come to the end of its ISO ratification process (one way or another), not ODF.

    >> it’s like one of those trashy entertainment shows

    >> reporting on the Oscars, and ripping on everyone’s

    >> dress

    How about if one of those stars turned up at the Oscars wearing nothing at all?  I think *every* news station in the world  would be reporting on that one, trashy or not!!

    >> Spreadsheet Dates

    >> * There is a new date datetype for cell values,

    >> and the only way to store into that datatype is

    >> with ISO 8601

    Whoopee!  So, it’s just like ODF, isn’t it?  Except it isn’t.  Because it’s not actually implemented in OOXML yet, is it?  Sure, the 8601 change may have been "accepted" at the BRM – maybe it was even one of the few proposed changes that was actually discussed there – but has anybody even yet seen a final version of the spec that has this change in it?  Has anybody got a version of their Word Processor, Spreadsheet or translator that actually implements it?  And if so, how many customers have used them?  (These are not rhetorical questions: I’ve no direct involvement in the process, so I’ve no idea if anybody has or not).

    >> 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

    But the purpose of Fast Track isn’t to fix major problems.  It’s to give a final polish and stamp of approval to standards that people have been using already.  That’s not what’s happening here.  To say that the spec is better now than what you started with is irrelevant if it was so poor to begin with.  A week-old stinking fish with fresh cherry on the top is "better" than a week-old stinking fish all on its own.   (I nearly said something other than "a week-old stinking fish", but thought better of it!)

    Cheers,

    – Mike

  6. SteveL says:

    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.  

  7. Pour faire référence à mon précédent post , voici un petit compte rendu rapide de cette journée, ou plutôt

  8. Doug Mahugh says:

    Now that we’re getting down to the final days of the DIS29500 standards process, it’s interesting to

  9. Ian Easson says:

    @funnybroad

    Just look in past issues of this blog.  There are lots of lists of implementations of OOXML.

    There is also a website of implementations in Germany.  As I recall, the list is 126 implementaions for that country alone.  (No, I don’t remember the URL.)

    None of these lists include in-house "line-of-business" applications that utilize OOXML.  Such inhouse applications are for that business alone, and are not for sale.  Thus, the lists of OOXML applications significantly underestimate the work being done by developers.

    All these third parties say the same thing: it is very easy to implement.  

    And with the release of the OOXML SDK in a few months, anyone with Visual Studio should be able to do it pretty trivially.  And, please, no kneejerk reaction that the SDK is Windows-only.  There are similar toolkits being used today for Java, PHP, etc.

  10. Jake says:

    @Ian et al:

    While I don’t at all question the existence of a page listing over 100 "OOXML implementations" and risking that people don’t want to discuss about semantics, I’d like to more clearly define what’s counted as an "implementation".

    What I mean is that if MS OOXML SDK provides APIs and libraries (e.g., msooxml.dll) to produce and consume OOXML files, are all the application using the libs then really "OOXML implementations"? I think they’re not. IMHO there’s just one implementation and it’s OOXML SDK.

    This is just like with mshtml.dll, thousands of applications applications using it hardly are all "HTML implementations"?

    Due to level of abstractions in libraries and SDKs it is actually more important how many applications are directly accessing (some might even say *producing*) raw OOXML/ODF/HTML/whatever files than how many applications are using libraries for such a purpose because it’s only the code doing the raw access which actually needs to deal with all peculiarities of a standard or a protocol.

    Level of completeness is another issue. If I’ll write a five line script send and receive data over a socket have I created an implementation of TCP/IP then? Or a socket implementation? Again, I don’t think so. I would be just using something created by other people and my code would demonstrate absolutely nothing when discussing merits of TCP/IP or sockets.

  11. Ian Easson says:

    Jake,

    It is the OOXML standard itself that defines what is an "implementation".  By that definition, all what I talked about are implementations.

  12. Ian Easson says:

    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.  

  13. funnybroad says:

    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.    

  14. Megaloman says:

    I don’t understand why do we need another standard which does the same as an existing one? It’s like to do what’s already done.

    Why are you moaning that ODF is bad and Open XML is better? ODF is already an ISO standard and rather trying to kill it, microsoft should work together with other companies to improve it. why microsoft doesn’t want to implement ODF in Office Suite? I know there are “convertors”, but it’s not a real solution, is it? imagine, Windows Media Player wants to convert all mp3 files to wma files before it plays them…

    it’s all about market and money – microsoft is scared, that it might loose it’s main money source. why? because if the ODF would became a real standard and Office would have it implemented, users would prefer to use free alternatives instead of Offise Suite, or microsft would have to prices down…

  15. LarryOsterman says:

    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.

  16. Dan Matei, președintele CT210 a anunțat rezultatul votului de marți : Pro: 15 Contra: 6 Abtinere: 5 Astfel,

  17. Anonymous Coward says:

    "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.

  18. LarryOsterman says:

    AC: You’re buying into the there "must only be one" falacy.

    There have been multiple MUA protocols for a really long time and neither one of them has "won".  Instead they both coexist quite happily, people chose the protocol based on their usage needs (POP3 is a download based MUA protocol, IMAP saves the email on the server, and as such allows access from multiple machines).

    Similarly, PDF and HTML both exist quite happily at the same time, neither is going to supplant the other – they’re both allow the representation of a document, but they do different things.

    There’s no reason to believe that either of these document formats is going to replace the other because they serve different needs.

  19. Anti-Open XML lobbyists have long been crying foul on some of the flaws in the specification. Two main

  20. CGR says:

    Folks, I think there’s way too much energy wasted in these ideology-oriented discussions!

    The point is that:

    1) ODF is an ISO Standard. It is not a perfect specification (there is no such thing).

    2) The standardization process of OOXML is being pushed forward by MS and I don’t really doubt that they will get their standardization.

    3) LET THE MARKET DECIDE WHICH OF THE TWO SPECIFICATIONS THE BETTER OR PREFERRED ONE IS! Why try to block something – if you hate it, don’t use it! If some of your business partners use the other format, you either use a converter (and don’t give me that crap "there are no converters"!) or – if you want to follow the "jihad"-like approach – you stop doing business with them!

    4) I would also like to remind you that, although OpenOffice is FREE, its overall TCO is NOT zero (far from that) and it depends on your own usage scenario. The same can be said about the usage of one format or the other: the costs and benefits depend on your specific scenario.

    In conclusion analyze what is good for you and leave this completely highly ideological discussion to the "true believers", who probably do not have to work for a living, otherwise they would not waste their time!

  21. el es says:

    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….

  22. Megaloman says:

    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.

  23. LarryOsterman says:

    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).  

  24. Jomar says:

    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 :)

  25. Megaloman says:

    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?

  26. Jomar says:

    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).

  27. jones206@hotmail.com says:

    Guys, it’s simple. There are obvious reasons for moving to an open xml format, and I’ve discussed those numerous times.

    While I know many of you don’t realize this, Open XML and ODF were developed in parallel. It’s not like we decided one day to move to an open format, looked at ODF, then decided to go in a different direction. Read my posts on the history for more background: http://blogs.msdn.com/brian_jones/archive/2007/07/09/open-xml-timeline.aspx

    In terms of why we care about having an open format, it’s pretty simple. Many people don’t think we want the format to be open because it would be business suicide. That’s actually not true though. We believe the by moving to an open format, it actually can help our business (and others).

    Even with our formats being open, in our mind, most of our customers will not move to other products because we offer the best Office suite. No one comes close in terms of usability, features, etc. That’s our opinion and it’s what drives our decisions. You may disagree with us, but we firmly believe it, and that’s why we’ve made the decisions we have.

    The data inside of the files folks creat is extremely valuable. By opening that data up and allowing other solutions to operate on the data, the value of those documents increases dramatically (orders of magnitude). This increase in the value of documents increases the value of the applications that work with these documents. It grows the marketplace, so that even if our share of the pie stays the same percentage-wise (or even decreases slightly), overall there is more pie, so we win.

    The key thing we need though is an open format that our customers will actually use (otherwise what’s the point?). If we were to use ODF, there would be feature loss, and our customers would lose confidence both in the format and in the application. We need a format that allows our customers to continue saving their files without risk of data-loss. That’s what drove the original design goals of Open XML. ODF started it’s development around the same time, but the design goals were much different. The PDF for the ODF 1.1 specification still has the title "OASIS Open Office Specification"… it’s clear where it’s roots come from.

    -Brian

  28. Jomar says:

    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

  29. jones206@hotmail.com says:

    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

  30. Jomar says:

    Brian,

    I’m breathing…

    Don’t pretend that you don’t know what I’m talking about, ok.

    We both was at the BRM and you know exactly what I’m saying (or you do not remember the wait-one-more-day Brazilian Proposal)… If you forgot, take a look here:http://homembit.com/2008/03/at-the-end-what-we-did-in-geneva.html

    And breath a while too :)

    Jomar

  31. jones206@hotmail.com says:

    I think I’m breathing :-)

    Jomar, I’m curious how we could have created a brand new document that defines a binary to Open XML mapping as part of the ISO process. The document doesn’t exist, and it wasn’t part of the scope or goals of Open XML. Trying to create such a document would definitely take a lot more time, and it’s not necessary for Open XML to be useful. The goal of Open XML was to create a format that would allow anyone with files in the legacy formats to write into an XML format that was capable of representing everything in those files.

    The goal wasn’t to provide people with information on binary formats, rather for people who already understood the binary formats (OpenOffice, Corel Office, Microsoft Office, Gnumeric, iWork, etc.) we wanted to provide an XML format they could use without loss of fidelity.

    There is no document out there that lists binary mapping behaviors. There is the binary documentation (which is available from the British Library and the US Library of Congress), and there is the Open XML documentation, which is available from Ecma and hopefully soon ISO.

    It could be that a new work stream gets created to build a document that provides binary mapping, but I’m not sure how many different groups need that and how much interest there would be. Once the migration happens, folks will build around Open XML, and not the binary formats.

    We (Microsoft) thought that more interesting than a document would be actual source code. That’s why, rather than start a project to create the documentation we started a project on source forge to map from the binary formats into Open XML with actual code.

    -Brian

  32. Megaloman says:

    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.

  33. CGR says:

    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.

  34. Andrew says:

    @Megaloman

    You are clearly not reading Brian’s posts as he has answered your question succinctly.  

  35. Megaloman says:

    @Andrew

    I am reading, but he has not given any good reason to create another standard. The reason "because SUN and IBM created" is not a reason – Microsoft would have joined them and helped them to create ODF, but did not. or "because customers expecting something from Microsoft"? if Microsoft would implement ODF in Office Suite, customers would have benefits only. Or maybe because "OpenXML" is better? is it really? why Microsoft does not want to make ODF better?

    Open Document Format is an existing ISO standard and it should not be doubled with any other document format. As simple as that. Customers would benefit more from one standard. Microsoft and Brain is simply playing with words – customers should have a choice – of course! they should have a choice which office suite they want to use. If OpenXML became an ISO standard, customers won’t have any choice, as OpenXML will be kept as Microsoft’s proprietary format and probably any MS Office version won’t have full support for it.

    as I wrote it, Brian and other OpenXML advocates are repeating and spreading FUD – they mixing software and format and playing with words they trying to force their will. As we have seen in many countries, Microsoft was paying for votes and was forcing its customers and partners to vote for OpenXML. That clearly gives me an idea that all this is about money and market and Microsoft is afraid, that they are going to loose market if won’t make their proprietary solution an ISO standard.

    I thought, that Brian will give me a good reason to convince me that OpenXML is needed, but I can see, there are no good reasons. Microsoft basically cares about its income and nothing more. Shame. EOT from my side.

  36. david_leblanc says:

    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.

  37. Jomar says:

    Cool !!!

    Now David is also studying ODF !!!

    This MUST means something !!!

    []’s

    Jomar

  38. When you tell a lie often enough, it takes on a patina of truth each time it is uttered, and after a

  39. When you tell a lie often enough, it takes on a patina of truth each time it is uttered, and after a