다음을 통해 공유

Open XML in Science and Nature; Deploying Office 2007; and more…

  • 아티클

Here are a few interesting links I came across this week:

  • Open XML in Science and Nature - Murray Sargent gives another update on the discussions we've been having with the folks from Science as well as Nature. They have some really cool publishing processes, and unfortunately we're only now talking to them about how to integrate the new file formats and the new math functionality into their existing process. In the end we should see some pretty cool functionality, but it's still a bit too early.
  • Deploying Office 2007 – The word team blog has a post with some details on how to ease the transition over to Word 2007.
  • More on the IBM support of OpenXML – Stephen McGibbon has a couple posts now talking about both the IBM article which describes how you can easily build solutions on top of OpenXML; as well as some information on potential OpenXML support in Lotus notes. The article on building solutions on top of OpenXML for some reason is no longer available, but Stephen has a copy you can still get to: https://notes2self.net/pages/stephen-s-cache-of-google-s-cache-of-ibm-s-openxml-document.aspx
  • Open standards advocate comes out in favour of Microsoft - The Bangkok post has an interview with Rick Jelliffe where he disputes the arguments currently being used against OpenXML.
  • Microsoft opens up its data format – Interesting article from the National Business Review that talks about the shift we made a couple years ago from proprietary binary formats to open XML formats.
  • Package Explorer 3.0 – Wouter van Vugt has updated his package explorer tool with added functionality for creating new documents and parts; signing documents; viewing signatures; and some loc work.
  • More on Word's mediocre XML – Good writeup, and super valuable discussion in the comments section. I need to pull together some information on this one for a future post. Bob's done a lot of thinking here and put down some really good information on the design of the WordprocessingML format. I think that a key area of confusion though comes from the initial design goals. The wordprocessingML format wasn't designed to be the ultimate XML format for representing documents. There are already tons of formats out there that do just that. The purpose of wordprocessingML was to be an open xml format that could fully represent the existing base of Word binary documents. We wanted to take everything from that world, and bring it into the new world. That's why I've always said that we have no issue with ODF, or any other format for that matter. ODF was designed to achieve different goals, and it's perfectly acceptable to have both formats exist as standards. The work that DIN is doing to create translations is super critical for this same reason.

Comments

  • Anonymous
    June 13, 2007
    It seems you're a real Open XML expert :) Could you please have a look at the DOCX-files on the following page? http://pschmid.net/office2007/forums/viewtopic.php?p=657 Why do these documents have the wrong font when opened with the compatibility pack on Word 2000 but do open ok with Word XP?

  • Anonymous
    June 13, 2007
    2 years... But it's still very early. Sole purpose is 100% backwards compatibility... And yet interesting workflows need special help to upgrade. meh

  • Anonymous
    June 13, 2007
    The comment has been removed

  • Anonymous
    June 13, 2007
    "More on Word's mediocre XML" For the life of me, I thought I would never see an admission of truth like that. By the way, who worked on Word's XML? Let me add a few points. You can extend 'mediocre XML' to Excel and Powerpoint. In fact, you guys took the easy road (very strategic) and simply added angle brackets around binary formats. 15 years of legacy are not going away anytime soon. Just saying. So the formats were never designed with XML in mind. I wonder if this has anything to do with last week's US ISO CHAIR COMMITTEE comments that are now made public (http://www.ibiblio.org/bosak/v1mail/). It's an interesting event. Should such things happen only after you are being called out by authorities ? Also, when you said the new formats were created to be backwards compatible, you forgot two things :

  • the new chart drawing engine is incompatible with the old one. A ton of properties are lost when you migrate to the new file format.
  • the migration is new code and has plenty of bugs. I personally have to create workarounds for files that open well in Excel 97-2003 and not well in Excel 2007. And of course customers think I am the one being faulty here. In a nutshell, I have nothing against OOXML has a file format, but it should not be allowed to become an international standard since barely more than 5% is documented. (5% = 6,000 pages)

  • Anonymous
    June 13, 2007
    You also forgot to mention that Office 2007 documents are extensions of ECMA 376 documents. And those extensions are not documented.

  • Anonymous
    June 14, 2007
    Interesting links... a thought on fields: I was disappointed to see last year that fields are not represented as true XML constructs. This will make it that much harder for other developers to capitalize on Word's actually rather powerful fields (and integrate them, e.g., with content controls.) However, an even greater problem with fields is not that they are hard for developers, but for users. Most users don't use them, even for long, complex, and should-be-structured documents. One reason may be that even when users know about fields, they are hard to use. The way fields work now is like Excel before auto-recalculation: you have to press CTRL+A, F9 to update them. This means a lot of errors in printouts: from incorrect page numbers in TOC, to wrong headers in STYLEREFs, to broken/old content in INCLUDETEXT/PICTURE, to "Error!" messages in cross-references. In fact, the linear nature of fields means that sometimes pressing CTRL+A, F9 once is not enough (because updating one field can throw, e.g., page numbers in all others off.) I don't see any reason to XML-ify fields now. If/when, however, Word does start to represent fields internally with a live, relational data structure, changes in the file format will probably be necessary. That would be a great point to XML-ify fields.

  • Anonymous
    June 14, 2007
    Stefan, I'll take a look. I think I remember there being some issue around updating the fonts in older versions but I'm not positive.

finite, The product has only been available for about 6 months. If you read Murray's blog you'll see that the issue right now isn't the file formats, but it is the new math support. There is a brand new math engine in Word, and that functionality isn't supported in older versions of Word. Since both Science and Nature have their workflows built around Word 2003, they're still trying to figure out how to best support the new math.

Stephane, I was one of the folks who worked on the original WordprocessingML from Word 2003. It was absolutely designed with XML in mind, but not with the traditional DocBook/SGML view of document publishing. Traditional Word documents are not at all structured. Even things like Headings are just formatted paragraphs. The wordprocessingML format is an XML format that maps to that flat structure. Content controls and custom defined schema are the way we enable people to add additional structure. To your other point, other than the things we've already talked about like VBA; document encryption; and some markup around application specific UI everything is in the Ecma spec.

Francis, That's the way we thought of it. The field support has been around for a long time, and has behaved the same way release to release. The XML storage of those fields is pretty similar to how they are in the document. They aren't a structured region, but instead a place where field code instructions can be inserted that specify the behavior. If at some point in the future we decide to make fields more structured, I would imagine that being something we'd work with Ecma to update in the file format as well. -Brian

  • Anonymous
    June 14, 2007
    Stephane: The US ISO committee chair (the chair of INCITS V1) is Patrick Durusau, a founder of the OpenDocument Foundation and one of the architects of ODF, so you would expect him to have a thing or two to say about the "quality" of OOXML.   I can guess that you know this (seeing how vocal you are with regards to the whole standardization effort), but chose to omit this piece of information to make him seem more "authoritative."  I have yet to really understand why you're so rabidly anti-OOXML considering that you are personally familiar with the pain of parsing the old formats.  Are you that afraid that your product will have no market??

  • Anonymous
    June 14, 2007
    nksingh, "you would expect him to have a thing or two to say about the "quality" of OOXML. " Indeed. Isn't it what I've said? Mr Durusau has recently explained that OOXML is documented at the syntactic level, not at the semantic level. This is enough to stop the ISO standard process. And by the way, this is one thing I have been saying for almost a year. Just that, being a third-party, Microsoft chose to ignore. I have also complained about the fact that Microsoft generally ignores third-parties to their own advantage : they'll happily say the automating Word/Excel/Powerpoint on a server is perhaps not reliable (or too slow), but what they don't say is that there is a ton of third parties out there to fill this need. (I am not talking about me specifically here). A reality check does not hurt sometimes... "I have yet to really understand why you're so rabidly anti-OOXML considering that you are personally familiar with the pain of parsing the old formats." Because I am but a few who have really IMPLEMENTED the specs. You know, I have two products, and one of them does UNDERSTAND the format, it's not only reading angle brackets contrary to many of the projects starting here and there (that's why XML is such a marketing joke). Even Mr Brian Jones who will speak at length about this thing hasn't. (correct me if I am wrong) In fact, none of the public voices from the MS Office blogs have. That's what makes it so ironic. But in his latest post where he admits "mediocre XML", he's admitting the sin. That's a start. "Are you that afraid that your product will have no market??" You don't understand. Microsoft is leaving huge gaps for me and others to make business in niches.

  • Anonymous
    June 14, 2007
    The comment has been removed

  • Anonymous
    June 14, 2007
    Stephane, when you spout nonsense like 'the 6000 page OOXML spec only documents 5% of OOXML', you lose all credibility.

  • Anonymous
    June 14, 2007
    The comment has been removed

  • Anonymous
    June 14, 2007
    @Stephane Actually I found that ODF seemed to lack a lot more to implement it's spec than OOXML. In it's basic spec it allows for very weird combinations of code to implement. Allthough OOXML certainly isn't ideal and could still use a lot of improving it seems much more structured for implementation than ODF actually is. As it stands for instance I can forsee that even in 5 years it won't be a problem to implement ODF which is conforming with the specification but which won't translate to a document correctly in most implementations because implementations are not capaple of dealing with complexity. Basically what both specs need is reference implementations and examples because frankly with just a spec to go on there is now way either format will lead to interoperable implementations. At the moment it look like ODF implementors are using OOo as a reference (at least for the parts OOo already implemented) and that OOXML implementers will use MS Office as a reference.

  • Anonymous
    June 14, 2007
    The comment has been removed

  • Anonymous
    June 15, 2007
    I do not exactly see how your example makes OOXML differ from ODF or why that should be simpler. Also I would think dat in a spreadsheet if anything you would look for data in cells and I do not think that is a lot easier in ODF and I still do not know what is supposed to happen when in ODF you make the data in a table cell differ from the data in the cell property. I find a lot of things easy in OOXML because of it structured aproach by which you have a treelike structure which is also defined in the spec. So implementing a part of the spec only required a particular branch of the tree supported whereas it seems ODF has less of such a structure and needing most of the spec supported for only a particular document type for instance. In OOXML I like the OPC but I find the VML inclusion ridiculous but as a whole the specs is fairly acceptable. ODF has a nice clean setup with little burden of legacy stuff but is complex to implement and if MS were to implement it it would probably produce a simular size spec of just extentions to ODF which would not help anybody. And on those comments: You call them ISO comments but it seems you could also say that they are OpenDocument Foundation comments. It is like naming Rob Weir comments on OOXML ANSI comments while me and just about anybody else would see them in the context of Rob Weir portraying the IBM point of view. I am not calling Brian comments ECMA comments but Micrsoft comments and so on. Actually the amount of people with an agenda in these kind of public committees startles me.

  • Anonymous
    June 15, 2007
    The comment has been removed

  • Anonymous
    June 15, 2007
    Stephane, is your issue with the documentation, or the format itself? The format does not convey semantics any more than the application itself (though the object model or UI) conveys semantics. Word has the concept of paragraphs, tables, formatting, etc. Excel has the concept of rows, columns, equations, pivot tables, etc. All of that information is represented via the XML, and all of the XML is fully documented. If you want semantics beyond what the applications themselves support, there are some options though including custom XML and content controls. If your issue is with the documentation, what more are you looking for? Are you refering to the things that aren't part of the standard like encryption and macros? Or is there something else you're trying to get at? Lastly, while I know you don't want to talk about ODF and OpenXML together, that's what the current issue is. IBM and others are pushing for legislation that would require ODF and block OpenXML. What do you see in the ODF format that you like better than the OpenXML format? Or do you think both formats should not be standards? -Brian

  • Anonymous
    June 15, 2007
    The comment has been removed

  • Anonymous
    June 15, 2007
    Stephane, Please understand that no one reading this blog has a clue what points you are trying to make.  Maybe it's just me, but all that I can get out of what you have written is that the OOXML standard has no "semantics", and in your opinion makes it too difficult for developers to write code to render the document.  Pardon the pun, but no one knows what you mean by "semantics"!

  • Anonymous
    June 15, 2007
    The comment has been removed

  • Anonymous
    June 15, 2007
    Ia, "Pardon the pun, but no one knows what you mean by "semantics"!" If you try to implement the specs, you'll soon realize what the semantics is about. In a nutshell, it's programmatic access versus document instances. Someone at ISO said it better than me here : http://www.ibiblio.org/bosak/v1mail/200706/2007Jun05-132133.eml

  • Anonymous
    June 15, 2007
    Stephan, Sorry, I don't have the time to try and implement the specs in order to understand what you are talking about.  To call it "programmatic access versus document instances" is no help either --- that's another total opaque phrase that just does not mean anything to me.   However, I did carefully read the document you referred to.  What I can make of it is that the people writing it have a background in theoretical models of what an ideal document should be -- e.g., it's a heirarchy with rules such as "Heading 2 is subordinate to Heading 1".  By their own admission, they have a great deal of trouble understanding or appreciating OOXML because it does not have such a fixed ideal model of what a document should be.  That is because the application that ultimately spawned it (MS Office) has no such ideal model built-in, and the over-riding design goal of OOXML is to be able to faithfully reflect the contents of those existing documents. If that's what's bothering you too, then there is no way of possibly satisfying you.  (The billions of existing documents are not going to go away, and the market need for OOXML, i.e., for an open standardizied XML format that can faithfully reflect their contents is a real one.) Am I correct in my understanding?

  • Anonymous
    June 15, 2007
    The comment has been removed

  • Anonymous
    June 15, 2007
    Stephane, If you have been having problems with Open XML, why don't you help document the errors and workarounds/solutions you have found? That would be a great help for other implementers as well as for Microsoft in fine-tuning the standard and preparing future versions. Take a look at this web site to see what I mean: http://www.xmlopen.org/ooxml-wiki/index.php/DIS_29500_Comments Along with constructive and pointed criticism, it is a wealth of information on the typos that unfortunately made it into the spec and may [understandably] frustrate developers like you.

  • Anonymous
    June 15, 2007
    Ian, "Sorry, I don't have the time to try and implement the specs" So then, how legitimate are you in your criticism ?

  • Anonymous
    June 15, 2007
    The comment has been removed

  • Anonymous
    June 16, 2007
    Brian, (sorry to interrupt, Stephane, I'm afraid I have to agree with you ;) if you want an idea of the respect Microsoft's formats are generally held in, you might like to wander over to this web site: http://www.jsware.net/jsware/msicode.php3 I was looking for an implementation of the MSI installer for Linux and Solaris, and Google pointed me in that direction.  So I found this: "Windows Installer (WI) refers to using MSI database files as the "housing" for a software installation. An MSI file used to install software through WI contains the software install settings and usually contains the software itself, packed inside the MSI. Unfortunately, the Windows Installer system is extremely - even bizarrely - complex. It uses an MSI database that contains approximately 80 tables, with extensive cross-referencing between the various columns of those tables. "The structure of MSI databases, when they are used as Windows Installer installation files, is so complex, convoluted and poorly designed, with data so heavily cross-referenced - and the available tools are so limited - that few software developers using WI actually create their own installation files. The basic software installer tasks of creating simple dialogue windows, copying files to the system, etc. are daunting challenges under the WI system. Windows Installer is so difficult to use that most software developers who ship MSI installation packages build them with some kind of 3rd-party software built on top of the WI system. And some of those 3rd-party systems, such as InstallShield, just cram their own installer EXEs into the MSI so that they can provide whatever functionality they want to while still honoring Microsoft's MSI "standard"." Might it be that there is a genuine problem with Microsoft's various formats?  I mean, I had to go to Port 25 to suggest a way to "defang" the early ActiveX dependency in what is now ECMA 376.  If I had to go to a totally different part of Microsoft from Office to get a worrying malware vulnerability in the original MS OOXML specification worked out, then there is definitely something wrong with the specs and I'd suggest Microsoft slow down and do rather more work on it, and allow independent implementers to work out all the bugs. That's not politics, it's just good sense.

  • Anonymous
    June 18, 2007
    Hey guys, the discussion here seem to be all over the place. :-) They are very good discussions, but it's hard to keep up. I think what I'll do is pull together a post that goes into the actual content model of the wordprocessingML format. That should help clear things up. The short of it though is that the formats were absolutely designed with XML in mind. They just weren't designed to fit into the SGML/DocBook model of what a document is. They were designed to match Word's existing content model, which is why we stress how important backward compatibility was for us. We weren't trying to create the ultimate general purpose XML formats. We were creating an XML representation of Office documents. Wesley, I think in any spec you'll see bugs. It wouldn't have made sense to delay the standardization of the Ecma spec for misspellings, etc. All specs have bugs. Heck, look how many versions of ODF there are out there already (and it still has huge holes they they are working to fill). I'm not sure what you mean about the Port 25 thing. The ActiveX issue was brought up by one of the TC members, and we all decided to change it. There was a public alias though that everyone was free to use though, and we were pretty vocal about that. We released public updates to the spec every couple months during the standardization process and had the public feedback alias going as well. That will continue to be available as we move forward with future versions of the spec too. -Brian

  • Anonymous
    June 18, 2007
    The comment has been removed

  • Anonymous
    June 18, 2007
    Stephane, if you like the design decisions of ODF better, than feel free to use that format. You keep talking about the Ecma specs being a joke, and that they only contain 5% of what's needed for implementation. Could you point me to a file format specification that is closer to what you're looking for? The ODF spec has even less information than the OpenXML spec, so there must be something else you're expecting... I gotta tell you man, I don't really know what you're looking for. Maybe it's just me, but I have no clue what you want. Do you want Ecma to stop the ISO submission and maintain the ownership of the spec? I would think that having ISO own the spec would be a good thing. Do you just want more documentation? I feel like I've been very open and honest with you for the past couple years I've been blogging. You're constantly negative responses to everything I say though are really getting old. Do you ever have a polite discussion, or is this just the way you are? -Brian

  • Anonymous
    June 19, 2007
    Brian, Yes, this dialog with Stephane is pretty useless.  He never makes it clear what his objections are or what he is looking for.  But here are my guesses, reading the tea leaves:

  • He wants Microsoft to build a new version of Microsoft Office (both the application and the file format) that is organized around SGML/Docbook paradigm
  • He then wants Microsoft to release not just the new file format spec for this new version, but also complete application specifications so he can then create a clone of it.  (I deduce this from his latest comment in which he says "only 5% of what's needed to implement an Office alternative is documented" -- my **) As I said in an earlier post, there is thus no practical way he can be satisfied.

  • Anonymous
    June 19, 2007
    The comment has been removed

  • Anonymous
    June 19, 2007
    Ian, Get a life.

  • Anonymous
    June 19, 2007
    I think you should tone down your argument style. The fact that i am interested in Office formats has everything to do with implementing them however I probalby have way different goals then you have. I am looking for implementions created from applications that combine data into template wordprocessing documents and delivering large amount of applications data into complex spreadsheets. I am interested in converted our old millions of automatically created and electonically archived documents and retrieving data from them. I am not looking for rendering office documents using the spec as you seem to be. Rendering complex documents like office documents requires heavy complex applications espcially if you want to build everything yourself without using provided api's. Anybody who thinks the office document specs are enabling people to build office functionality should be well aware that office suite applications require many thousands of man hours to build. These formats are not building blocks for that and will never be. but if you have build Office functionality then it is fairly easy to pick the format specs and see which part you can support and which not. You can build converters, importfilters and even decide to change your native format (the latter being a big change). [quote]One example : those 3 formats use VML all over the place.[/quote]I am not sure what you mean. The format spec identifies VML to be deprecated and thus only needed for converted office 2003 XML format files. Why would anyone but Microsoft even attempt to support that part of the spec.

  • Anonymous
    June 19, 2007
    The comment has been removed

  • Anonymous
    June 19, 2007
    "I am not sure what you mean. The format spec identifies VML to be deprecated and thus only needed for converted office 2003 XML format files. Why would anyone but Microsoft even attempt to support that part of the spec." This "deprecate thing" is a marketing trick. It isn't. VML is all over the place in the new file formats. The Excel team has even ADDED VML dependencies in objects such as spreadsheet sticky notes. As to whether you don't have to, again, if you intend to render a document to a screen or a printer, how can you avoid to implement VML too ? Another marketing trick about VML is that there is a chapter about VML in the 6,000 pages. But the semantics is not there, only the syntax.

  • Anonymous
    June 19, 2007
    If you are willing to take a minute or two to follow those steps and see for yourself if VML is "deprecate" or not : Create a new Excel 2007 spreadsheet ; right-click on a cell and choose "Insert comment" ; type some comment ; save the spreadsheet ; close it. Now unzip it and, surprise, surprise, a VML part is waiting for you. The VML describes the layout of the sticky note. There is no way a "deprecate" thing, if it was really deprecate, would be created with a NEW instance of an Excel 2007 file. Lookup "deprecate" in whatever dictionary, and I'm sure you'll come up with a sound definition. What "deprecate" means in theory is that VML may appear if you are opening an OLD file. But it's not true, as my simple example shows. Not convinced yet? If those sticky notes were expressed using DrawingML, and the corresponding markup would be entirely documented (syntax and semantics), then that'd be perfectly fine. Regardless of the documentation, if those sticky notes were expressed using DrawingML, that would be a first step. It would not just make sense, it would avoid Jones and others to lie in public. VML is pervasive in all 3 file formats. And VML is only one example, that I delibarately chose because BillG is also involved. Truth be told, there is an untold story here. It's been going on for more than a decade, and it's probable that the Office team is losing at their own game. In short, each MS Office release is never so comprehensive as to advance a new layer (such as DrawingML) in the file formats so broadly that it has the same level of support in all 3 applications. Before DrawingML (E2O internally), there was VML (MSO internally). And before that, there was Powerpoint's vector graphics layer. This is really where it originates from. With every new release since Office 95, they have tried to use "shared libraries", but never quite got to make releases that made the "shared libraries" equally supported in all 3 applications. In Office 12, it so happens that VML is still there, although the longer term is to go with DrawingML. What's just bad here is that Microsoft is deliberately avoiding to speak about it, and still push the file format so it becomes an international standard. But technically speaking, they are not there yet. The move to DrawingML is not complete in Office 12. Perhaps it will in Office 14 (i.e. MS Office's next release). Then, and only then, it will become fair to push it to international standards. Well, that is, if the semantics is documented too. But at least that would be a sign of progress.

  • Anonymous
    June 19, 2007
    (sorry for commenting so much) Office 12 versus Office 14 What the above says is that Office 12 is not a reference implementation of the OOXML specs. In OOXML specs, it says VML is deprecate. Office 12 actual implementation does not make it deprecate at all, as the example is showing. That's the case of a serpent biting itself. Isn't it ironic, a sane person should find it hard that a file format become an international standard when there is only one REFERENCE implementation. Which is the reality, there is no non-Microsoft implementation of the specs out there, and by implementation I mean something intended to do the same thing (not something playing it on TV). But what is this person supposed to think when the so-called REFERENCE implementation is not even a REFERENCE implementation? Office 14 may be better at it. But from an international standard standpoint : there is not even ONE STRICT REFERENCE implementation out there.

  • Anonymous
    June 20, 2007
    Stephane, By your tortured logic, ODF should have not become an international standard because there is not one implementation yet that supports the full spec. Not to nitpick, by you also incorrectly attributed the statement of Word XML being mediocre to Brian.   Read closely.  Brian quoted the headline of a post in Bob DuCharme’s blog.   Brian’s actual comment concerned the design goals of Word XML.

  • Anonymous
    June 20, 2007
    Angus, Your rhethoric does not get you anywhere. We are talking OOXML here.

  • Anonymous
    June 20, 2007
    I can agree with you that Office 2007 might possibly not fully adhere to the current OOXML specs but as you consider a reference implementation important where were you two years ago with ODF implementation as that did not have a full reference implementation then and still does not have one today. You consider the format to be the think you can build office functionality on. That is only fine if you duplicate MS Office. If you have your own office suite of your own application designed you do not use the format as a templete for your application but you use your application as a basis and use whatever from OOXML fits into that. It is unlikely more than 10 companies/organisation are capaple of producing full implementation on such a scale that they can fully render all MS Office functionality and edit all of it as well. If you consider that the most important factor in these Office formats you will be disappointed. Why would you ?

  • Anonymous
    June 20, 2007
    The comment has been removed

  • Anonymous
    June 21, 2007
    [quote]This is what the international standard is for[/quote] Not it isn't. A standard Office format is not just to create clone Office applications with all the same features. Also there is no need for 100% interoperability between documents created such applications. If that were the case than creating standards is only stiffling innovation. An open office format need to create a certain amount of interoperability which is nescesary for the required task. The more complex the task the more complex the documents will be that are exchanged and the more features you need to support on both end. Governments that want interoperability should not use extremly complex office documents with custom extension features or macro's even if they are in an open format. But internal company documents could have a really complex custom extensions to integrate them into specific Office applications. (For instance adding digital organisation specific archive info in your documents using a custom schema making all documents automatically archivable). Interoperabiltiy with such difficult office documents formats will require the use of simple documents and the ability for implementing applications to ignore certain not implemented complexer parts of the format without compromising those documents. It is fairly easy in current OOXML and ODF format specs to create documents that cannot be correctly read by any implementation. However there are also tons of applications that manage to be fairly interoperabel with the not open binary format of MS office even though they implement a lot less features than that Office suite. This can drastically improve using the OOXML format as those application can now much easier extend their interoperability with such formats and still not feel the need to support every feature that a company like Microsoft has decided to support.

  • Anonymous
    June 21, 2007
    The comment has been removed

  • Anonymous
    June 21, 2007
    The comment has been removed

  • Anonymous
    June 21, 2007
    The comment has been removed

  • Anonymous
    June 21, 2007
    The comment has been removed

  • Anonymous
    June 21, 2007
    The comment has been removed

  • Anonymous
    June 22, 2007
    The comment has been removed

  • Anonymous
    June 22, 2007
    In closing, as the owner of this blog can't bother even provide a sound argument, I'll recommend first of all anyone to read comments from the US ISO committee who appear to be public. Such as this one : http://www.ibiblio.org/bosak/v1mail/200706/2007Jun21-121337.eml And, to others, who really think what they think, I shall simply remind them that file format experts have seen this story before, have learned what Microsoft does, and the best of what they can do in this "david versus goliath" combat is to warn adopters. To warn adopters that it is very hard to reconcile "MS's Office Open XML gives freedom from Office applications" and "OBA scenarios will work with $20,000+ worth of MS Office product licenses", both of which are coming from the horse's mouth. Up to you guys. And at least, this thread got me the opportunity to learn where the heart of the commenters above go towards.

  • Anonymous
    June 25, 2007
    Stephane, I imagine Brian doesn't bother to reply because it's pointless.  Tirades generally win in comment forums. Continuous linking to material by persons who have obvious conflict of interest does not buy my vote. Andrew Hilton