500+ national body comments posting today


Ecma is posting a new status update today. We’re in progress updating 500+ new national body comments. As we head into a brief holiday break, we’re pretty happy about the progress we’ve made so far. I think the comments this week are the most significant changes we’ve proposed yet, so I wanted to explain what we did conceptually.


At a high level, we’re responding to feedback that requested simplification for those people who only wanted to implement a subset of the spec. We are also removing from the main specification functionality that is necessary for completeness but is not necessarily appropriate for documents created in the future. We’re moving that funtionality to an annex. And finally, we fixed some concerns that National Bodies had about how to handle some legacy issues, Dates in particular with the infamous “date leap bug”.


Implementing portions of the spec


We got a lot of comments inside the ISO process and externally from ISO that people may want to use only word processing portion (and not the presentation portion,) or wanted to build spreadsheets but not word processing files, etc. We’ve been working to make that easier.


TC45 and the project editor have worked pretty hard on the conformance areas in particular. We’re proposing the introduction of conformance classes to the specification. Five conformance classes will be created to define how developers can implement portions of the specification. WordProcessingML, SpreadsheetML, PresentationML, Open Packaging Conventions and Markup Extensibility will all have separate conformance classes within the specification. The advantage of conformance classes is that other classes can be introduced later if more granularity is needed. Other significant changes to conformance include the addition of semantic conformance, and a clearer definition of conformance for Open XML producers and consumers. This should make the spec more accessible to people because it is a lot easier to isolate specific areas.


VML and the Annex for Deprecated Features


VML has been a bit of a lightning rod around the world with Open XML. We received many requests to remove references to VML from the main body of the specification, so that documents in the future would use DrawingML only. In our proposal, we made the necessary changes to enable the usage of DrawingML everywhere VML was previously used. This will ensure that new documents will fully utilize DrawingML, as provided for by the new conformance clause. VML will be extracted from the main spec and moved to an annex for deprecated features.


TC-45 worked to accommodate the feedback from many national bodies that a subset of Open XML features are not necessarily appropriate for documents created in the future. The TC recognized that VML, Compatibility Settings (things like the famous “AutoSpaceLikeWord95”) , the “leap year bug” and a few other legacy issues should be extracted from the main specification and grouped in an annex in order to make it clear to developers that they should not be using them except in very specific cases.


Other ISO standards (such as SQL’s ISO 9075:2003 Part 1 and C++’s ISO/IEC 14882:1998) have a similar Annex that lists deprecated features. We decided to go further and to physically extract all those features (and their actual descriptions) from the main specification and move them to this annex. Our proposal is intended to clearly distinguish defects and deprecated functionality from what will be best for new documents.


Ecma TC-45 envisioned a need for a transitional period during which some existing binary documents being migrated to DIS 29500 can make use of those features. But the TC also wants to make it more clear in the spec that new documents should not use them. The proposal states that these deprecated features are not guaranteed to be part of the Standard in future revisions. Our proposal says:


“The intent is to enable the future DIS 29500 maintenance group to choose, at a later date, to remove this set of features from a revised version of DIS 29500.”


Compatibility Settings  – AutoSpaceLikeWord95


There has also been a lot of interest in the Compatibility Settings that include the famous “AutoSpaceLikeWord95” or “truncateFontHeightsLikeWP6”.   Ecma worked to provide in this batch the full information necessary to implement all compatibility settings without any dependency on any product. This documentation is provided for the completeness of the spec, but these features should not be used when creating new documents. I’ll discuss the compatibility settings in more detail in my next post.


Dates and the Leap Year Bug


National Bodies provided us also with a lot of feedback on the way we handle dates. Two weeks ago, we indicated how we proposed to use ISO-8601 Dates. In this drop, we provided more detailed information on how the proposed infamous “leap year” is fixed in the new date system, and how dates before 1900 could be now be represented.


All in all, this was a pretty big week for the spec and for TC-45, and it’s great to head into a holiday break with these dispositions on the table. I’ll be back in 2008 to share more of these with you.


As for my weekend, well you’ll find me at Qwest field Sunday cheering on the Seahawks. I usually don’t root for players on the the visiting team, but I am excited to see last year’s Heisman Trophy winner Troy Smith… I’m a Husky at heart, but I’ve always had a huge soft spot for the Ohio State Buckeyes. I’ll definitely be rooting for them during the (American college football) BCS championship game in January. Go bucks!


Happy holidays and Happy New Year everyone.

Comments (65)

  1. carlos says:

    "deprecated"

    the magic word to give the ilussion that you

    have changed the specification… without

    changing it !

    just throw away VML from this beast …

    or better:  put a

    <deprecated>

    </deprecated>

    element as root of all DIS 29500 XML, and

    start from scratch a really open,

    interoperable and reallistically implementable

    standard. Deprecate now all this XML description of a legacy binary format ( known as DIS 29500 ).

    Just a suggestion… hope it helps.

  2. jones206@hotmail.com says:

    Carlos,

    While you may feel like it’s not a significant change, you’re wrong. Not only is it now set up so that VML is never required (there is always a better alternative, such as DrawingML); the conformance clause has been updated to be clear that any new document should not use these deprecated features. They’re role in the specification is to help in the transition from the old binary world into the new XML world.

    All the deprecated features are now 100% fully documented, so anyone can implement them on any platform. At the same time, it’s also now set up in the spec and in the conformance clause that these elements serve a transitional role where new documents should not use them (similar to the transitional elements in HTML 4).

    This also means that we’ll have some work to do in Office in terms of the Open XML that we output in order to ensure we don’t use them for new documents.

    Please don’t be so naive as to thing that all of DIS 29500 should be deprecated. No other format meets this market need. Years ago people thought that the binary formats gave Office some kind of competetive advantage because issues around the availability of the documentation or the ease of use. We’ve now changed that. If you don’t like the format, don’t use it; but you should realize there are already tens of millions of people using these formats, and the standardization of these formats is very important.

    -Brian

  3. Doug Mahugh says:

    Ecma TC45 has uploaded to their web site proposed dispositions for 2298 of the 3522 total DIS 29500 comments

  4. Ecma TC45 has uploaded to their web site proposed dispositions for 2298 of the 3522 total DIS 29500 comments

  5. S says:

    The only reason VML was part of the specs is because you guys shipped VML in Office 2007 for new file formats (VML is used for creating web archives anyway (.mhtml), but that’s not the topic). And why did Office 2007 ship with VML? Because you urged the shipping of Office 2007 instead of finishing it. So what you call "important changes", is nothing more than what you should have done before submitting the spec to ECMA. In other words, the next version of Office 2007 will not create VML for new formats, because with two more years, you have finally found the time to finish the job. And that was the normal course, not changes required by external parties. You know that we know.

  6. S says:

    Brian said "Years ago people thought that the binary formats gave Office some kind of competetive advantage because issues around the availability of the documentation or the ease of use."

    Without making public the mapping tables between the binary formats and the new formats, Office 2007 retains the exclusivity when it comes to migrating binary formats to new formats in full-fidelity (in principle). So the competitive advantage is still here, and it’s in your favor (no big surprise here).

    Let me recap,

    Phase 1 – no DOCX/XLSX/PPTX out there

    While new formats are being created, Microsoft has to create a exclusive checkpoint, the migration checkpoint. Hence probably the reason why the mapping tables are not made public. Microsoft wants to keep the exclusivity. (In other words, the ECMA specs is just a diversion)

    Phase 2 – once there is enough DOCX/XLSX/PPTX documents out there, create new revisions of DOCX/XLSX/PPTX that are not documented in ECMA376 (or whatever we end up with). Even if Microsoft eventually publishes the changes, it can always do so 3, 4, 5 years later and use those years as a competitive advantage in a fast moving market.

  7. hAl says:

    S, you should take your paranoia to Groklaw.

  8. hAl says:

    @hAl,

    Paranoia? This describes exactly what’s going on. If you think I am wrong, you may want to provide arguments, rather than just behave like the Microsoft shill you are and have always been (you are posting pro-Microsoft posts like this, with no substance, in just about every single OOXML blog out there).

  9. zoobab says:

    @hAI, your comment is deprecated, you should it to an optional part of this blog.

  10. hAl says:

    There is no real argument against what you are imagening the future to be but just give you my ideas.

    What I can see is that Ecma is doing a good effeort in improving the standard to a level fit for ISO.

    For users like me that value compatibility and have invested time and effort in a ton of Office application solutions a format like this is very well appreciated and the more it improves the better.

    You suggest that Microsoft can change things outside the specification to fit new features in MS Office but I that they could do using any format even using ODF. What they can’t do in ODF is offer compatibility and the exact feature set they currently use.

    I for one rather have Microsoft producing a compatible format and use it than start using ODF and extending it to fit their needs  and making ODF some kindf of extension monster that has more features outside its spec than inside its spec.

    You suggest Micrsfot wants to have exclusivity on the conversion front. So what. That is actually what I as a customer prefer. I want a conversion that goes smooth and leaves the documents intact with as little risk as possible.

    I do not want a forced conversion to a new non compatible format because it is an iso  standard and the compatible format isn’t.

    If I ever decide to change to ODF as a format it should be because of ODF’s strenghts and clearly the conversion of current MS Office documents isn’t one of those ODF strength and is in no way a serieus choice.

    Also I do not want to change my office productchoice because of popel pushing through a office format that is not very compatible with the office prodcut I use. I rather wait until the product I use changes format with the confidence that it will be a smotth conversion.

    There is no limitation for me to ever start using ODF but I have not found that it currently fits what I need whilst as an MS Office user it seems OOXML is exactly what I need.

    And you know what.

    I think I am not the only office user that prefers an open standard format that combines their current productchoices with a completly documented and free to use format specification rather than take the a route of forced complex conversions and a different set of Office product features.

    But baffle us by creating superieur Office products that use ODF and we’ll consider it. and by then we will have much more faith in a conversion between two fully open specifications!!!

  11. S says:

    @hAl,

    Thanks for taking the time to answer!

    "There is no real argument against what you are imagening" ==> I’m talking about what’s going on right now. Office 2009 will not use VML anymore, that was part of the plan, only incomplete when Office 2007 shipped (now you understand why the Office group always ships on time…). The introduction of Office 2007, however you see it is the first time in a long time that Microsoft is asking their install base to make a switch. Sure you have a compatibility mode, but that’s just to smooth the transition. The reality is that the install base is told to make a switch. Very risky time for Microsoft, the install base could use it to 1) make a switch to an alternative 2) use it to put pressure on Office license prices.

    Microsoft’s strategy is to make the transition as seamless as possible. That’s just too risky a strategy without making sure the keys to the kingdom are secured, i.e. the mapping tables between the binary formats and the new formats.

    It’s not by accident that this stuff is NOT part of the ECMA specs.

    "For users like me" ==> At the risk of being harsh, Microsoft does not write software for you. They write software to appeal to large corporations all over the world. Until you see the issue from an asset preservation angle, you don’t understand what is at stake.

    If you could handle the ribbon, I guess you can be sold just about anything not strictly compatible with your existing documents and software.

    For corporations though, the ribbon alone is a big deal. No matter how Microsoft tried to make existing add-ins work as is with the ribbon, it so happens the ribbon breaks a number of add-ins. Imagine the consequence in corporations using add-ins.

    So what we are talking about here is not just document-level compatibility, it’s application-level compatibility. The ECMA 376 does not cover application-level stuff at all. It’s not in its scope. So if you keep saying that ECMA 376 improves, you are missing at least half of the bigger picture I’m afraid.

    "You suggest Micrsfot wants to have exclusivity on the conversion front. So what. That is actually what I as a customer prefer." ==> The customer wants exclusivity? I’m not sure what you mean. What I’m saying is that the exclusivity is key to Microsoft’s strategy in Phase 1, the switching period.

    "If I ever decide to change to ODF as a format it should be because of ODF’s strenghts and clearly the conversion of current MS Office documents" ==> On the one hand, you keep repeating that ODF is bad for working with binary formats. Not everyone agrees. And for this to make any sense, you have to provide details. One thing you could point out is VBA macros. But do you think Microsoft themselves aren’t going to pull the plug on VBA macros and introduce .NET in the picture? You bet! As for ODF itself, I think the real issue is extending ODF : it appears, based on what happened to Gary Edwards et al, that making those changes into OASIS TC takes a lot of time and is quite involved. This you can criticize, and that’s mostly political. But on the technical ground, I’m not sure you would have much to criticize.

    "I think I am not the only office user that prefers an open standard format that combines their current productchoices with a completly documented" ==> Most users have no idea what open standard format means. They see a .docx file, and they see what happens or not when they double-click on it. Period.

  12. S says:

    I forgot to mention that, for this exclusive migration strategy, Microsoft made important investments. Let me recap,

    – Office 2007 built-in migration module

    – Compatibility pack (per file)

    – Migration planner (bulk migration)

    Again, this does not happen by accident. And only them can go send the following message to their customers : "we reliably migrate your documents to the new formats. If you purchase licenses of Office 2007, we (only us) ensure the preservation of your asset."

    And saying so is nothing more than paraphrasing what Brian Jones says. Just with "exclusivity" removed. It does not hurt to make the ECMA specs publics following that logic, assuming that the ECMA specs does not hurt the exclusivity.

  13. ART says:

    @HAl: Microsoft is a dangerous company as it interferes into the inner politics of foreign nations and standard bodies. Therefore its own standard needs to fail regardless of its merits or shortcomings. It is a danger to democracy and the whole standard process got corrupted. They need to fail because they need to get real.

    I don’t care about the spec but as long as the patent conditions are so unclear as the OSP or the CNS. Technical comments are the only way to stop the ISO process.

    If the negotiation position of the international community is strong enough we all benefit: We would get more openness and even less vendor-lockin. There is no reason to be nice to Microsoft when they try to betray us. There is no reason to defend Microsoft unless you work for them. No one would be harmed from Microsoft’s failure to get the ISO standard as it is already an international ECMA standard. Microsoft did not offer much more to the international community. So what rational reason would there be to get it them for free, with nothing in return.

  14. orcmid says:

    I almost got too discouraged by the comments to continue down to the form.

    Brian, I think this effort is outstanding.  This is going to be one of the most-polished document format specifications provided in years.  If the ODF guys had been doing this to improve their specification, they would have made some welcome improvements to the usability of that spec.  

    I think the updated DIS 29500 is turning into a best-of-breed example that others will turn to for how to manage and organize a document-centric technology specification.

    I guess it really is a "that which does not kill me makes me strong" experience, huh?  

    Congratulations, happy holidays, and have a Happy, Joyous new year before and after February.

  15. Francis says:

    S: Your argument regarding the mapping between the old binary formats and OOXML, though interesting, is a red herring. That sort of information does not belong in a standard. Can you name any open format that specifies how old, closed formats are mapped to it? Does, e.g., the ODF standard instruct developers on how to migrate old StarOffice files to ODF?

    Including such details would necessitate mention of every single feature of the old, deprecated formats the new formats are intended to replace. This would bloat the specification as well as perpetuate and legitimate the preceding formats as part and parcel of their replacements!

    And yes, it is clear that the ultimate intent was for DrawingML to supplant VML, but the transition could not be achieved in time for product release. But is that a reason to object to the standards process per se? That it forces technological change that is better for all parties involved? I cannot see who stands to lose from VML’s deprecation or, thus, your bone of contention. It’s win-win!

  16. marc says:

    >Other ISO standards (such as SQL’s

    >ISO 9075:2003 Part 1 and C++’s

    >ISO/IEC 14882:1998)

    mmm, bjarn if you are reading this ( i doubt it … ) , i apologyze in name of Brian,

    for the comparision of DIS 29500 ( OOXML ) with C++ standard

    you know, sometimes you say things without thinking them

    sorry again

      marc

  17. Carlos says:

    [long post, sorry, i’m not Gary Edwards 😉 ]

    brian

    >If you don’t like the format, don’t use it;

    i don’t like to see the ISO standardization

    process subverted and the quality of

    its deliverables dramatically lowered

    >but you should realize there are already

    >tens of millions of people using these

    >formats, and the standardization of

    >these formats is very important.

    mmmm.. don’t agree here

    From this "millions" of people, 95% doesn’t care about this XML stuff.

    they just want to write "word files", send them via email and keep

    the receptor opening it without problems.

    The remaining %5 *really* cares and are really worried about *true* open,

    interoperable and implementable specifications

    Believe me, in its current form, DIS 29500 doesn’t qualify for this 5% people,

    and you won’t convince them just deprecating things.

    When i talk about the 5%, i’m not talking about the flamant ISO JTC1

    P-members suddenly interested in standards, who have voted inconditionally yes

    to this ( now deprecated ) +6000 pages beast:

    . Cyprus Island

    . Malta Island

    . Jamaica Island ( reggae paradise 🙂

    . Trinidad/Tobago island

    . Côte-d’Ivoire

    . Lebanon

    . Pakistan

    . Turkey

    I’m talking about people like Eric Kriss[1], from Massachussets, on of the people

    responsible of this sudden interest of your employer in open standards

    ( mmm, where is the good old Microsoft? [2] )

    A colofon: because *really* open standards like HTML, HTTP, TCP/IP, X-Window, RSS, C,

    C++, POSIX, hundreds of "Request for comments", etc exists, i can write this in

    an "alternative" OS: Ubuntu Linux 7.10, running an "alternative" browser: Firefox 3.0 beta 2,

    lot of kilometers away from you, through an open, implementable and interoperable internet.

    Brian and Microsoft, welcome to this new and ( unknown for you ) world of openness.

    You have lot to learn, yet. Keep working. But fast!! [3] ( to begin: support ODF natively in Office )

     Carlos

    [1] http://news.zdnet.com/2100-3513_22-5893208.html

     ( "Microsoft: We were railroaded in Massachusetts on ODF" article on zdnet )

    [2] http://antitrust.slated.org/www.iowaconsumercase.org/011607/2000/PX02991.pdf

     ( Bill Gates memo about customer lockin via proprietary extensions )

    [3] http://politics.slashdot.org/article.pl?sid=07/12/22/026216

     ( "Norway Mandates Government Use of ODF and PDF" slashdot article )

  18. Furu says:

    @Carlos: highhorsing much? 🙂 Bringing 11 year old memo as a proof of current policies is very slashdottish of you. Highhorse on and away, good buddy, we are discussing reality here.

  19. S says:

    @Francis,

    "That sort of information does not belong in a standard. "

    ECMA 376 is a migration format, that’s what Microsoft has sold us : a way to move forward while preserving the asset of billions of documents out there. By definition, it has to include the mapping tables. In fact, the destination format itslef needs not be specified in that spec, it belongs to something else.

    If the new formats were created from scratch though, the specs would have to define it. That is what happens with ODF for instance.

    Those who compare ECMA 376 and DIS26500 are actually comparing apples and oranges.

    "And yes, it is clear that the ultimate intent was for DrawingML to supplant VML, but the transition could not be achieved in time for product release. But is that a reason to object to the standards process per se?"

    You are mixing two different things. When I stated the obvious about VML, that was just to say that Microsoft was not being generous to other parties (which is why it’s more political than Brian Jones wants to admit) : that’s what they were doing internally anyway (for Office 2009). In a separate comment, I alluded to the mapping tables and how I see them being used to exclude competing products (hence Phase 1, and Phase 2). These are two different things.

    I’m not sure what you mean by "object to the standards".

  20. hAl says:

    There is something very interesting in this developement of the standard in the modularity suggesting by Ecma:

    "DIS 29500 will be reorganized into three distinct parts: DIS 29500-1 will consist of the WordProcessingML, SpreadsheetML, PresentationML, and supporting SharedML specifications; DIS 29500-2 will consist of the OPC (packaging) specification; and DIS 29500-3 will contain the Extensibility specification. This reorganization will simplify DIS 29500 for implementers."

    This is very good new for other XML file format implementations that will now be able to use the OPC as a seperately referenced specification.

  21. Ian Easson says:

    To add to what hAl said, making OPC a separately referenced specification is even more impotant.

    OPC is a base technology that can be used as part of a solution to link client- and server- based documents to documents in the "cloud". (This was discovered in another context by the Open Document Foundation folks, who realized that CDF — which is OPC’s poor disabled cousin —  can be used for that purpose.)

  22. S says:

    Today’s ECMA 376 :

    – Part 1: Fundamentals

    – Part 2: OPC

    – Part 3: Primer

    – Part 4: Markup reference

    – Part 5: Compatibility/Extensibility

    Part 1 and 3 are not normative, they really are just overviews and examples. So the really normative parts are 2, 4 and 5.

    Brian Jones announced that parts 2, 4 and 5 (OPC, Markup, Extensibility) will now, drum rolls, be made of 3 parts : OPC, Markup, Extensibility.

    This is huge huge huge guys!!! I agree with you for once.

  23. carlos says:

    >Bringing 11 year old memo as a proof

    >of current policies is very slashdottish of you.

    first of all: 2007-1998 == 9 != 11 !

    second:

    1998 is not so far my friend… are you feeling too old may be?

    actually, according brian jones, Microsoft "openness" efforts begun in 1998:

    http://blogs.msdn.com/brian_jones/archive/2007/07/09/open-xml-timeline.aspx

  24. hAl says:

    @carlos

    Looking at the timeline you could see that it was the XML formats that started in 1998 but making them open started with the MS Office 2003 XML formats in 2003.  

  25. S says:

    I think Microsoft’s original vision after 1997 (Office 97) was NetDocs, the codename of their project, a way to bind Office and Windows through Internet Explorer, and that’s where Bill Gates memo comes into the picture. That project failed, in and of itself and also with the help of antitrust charges. Beginning with 2004, Microsoft rushed to cover their asses as the threat of ODF getting better and better was becoming obvious. They rushed what became Office 2007, and they rushed what we now know as ECMA 376 just to screw the ODF standard and people adopting it.

    It’s 100% reactionary, since in 2004 they owned the Office document market. Nothing genuine.

    If you are not convinced yet, look what happened to Internet Explorer. Internet Explorer killed competitions for reasons that all we know, and even the Internet Explorer team was decimated. 5 years later, Firefox became a threat, and Microsoft reacted within two years with a new release of Internet Explorer that, drum rolls, replicated Firefox’s  most appealing features.

  26. Mike Brown says:

    >> Your argument regarding the mapping between the old binary formats and

    >> OOXML, though interesting, is a red herring. That sort of information

    >> does not belong in a standard.

    Correct!

    And that’s kind of the catch, isn’t it?  Microsoft’s entire raison d’etre for the existence of OOXML is the fidelity with the existing base of those zillions of MS Office documents.  And yet, they don’t give you all the info to do the conversion properly!

    How does moving AutoSpaceLikeWord95 and similar tags into the "deprecated" bucket help a developer trying to write code to convert .doc or .xls to OOXML?  If he comes across one of those tags, he’s got to do *something* with it, right?  What happens to his translated pages if he just ignores it?  (You can be sure that Microsoft’s own code won’t ignore these "deprecated" tags; their code will handle all them just dandy, because Microsoft actually knows how they’re supposed to work).

    As to the date bugs, again, congrats to Microsoft for at least no longer sticking its head in the sand on this one.  I mean "Ecma acknowledges that the date system should be correct" is quite a revelation.  Of course, it does rather beg the question, where were Ecma’s heads at when they were doing their own "review" of OOXML??  Presumably, they sat down together and agreed that it was perfectly okay, in a new standard, to have a date system that was "incorrect", and thought that they could get such a thing past ISO without any trouble.

    I’m curious though as to how this will work.  Again, how does somebody converting .xls to OOXML handle the bugged dates?  In fact, what qualifies as a bugged date in this context?  Obviously, Feb 29th 1900 does.  And I guess any date before then also does.  But in fact, are not *all* dates in MS binary documents bugged, if they’re all calculated from this "deprecated" counting system?  Does the revised spec mandate what the developer does with these dates?  Does he *have* to convert them to ISO 8601?  Is he told them to convert them whenever possible?  Is it (as I suspect) left entirely up to the developer as to what do with them?

    Cheers,

    – Mike

  27. hAl says:

    @S

    "Beginning with 2004, Microsoft rushed to cover their asses as the threat of ODF getting better and better was becoming obvious"

    You have a warped view. In 2004 the ‘ODF’ format was still called the OpenOffice XML formats and being developed by the Open Office XML TC in OASIS. So purely OpenOffice still.  It was still under development and OASIS had no plans to change it from an OpenOffice standardized format to a general office standard or even remotly to submit it to ISO.

  28. Ian Easson says:

    Mike Brown wrote:

    "How does moving AutoSpaceLikeWord95 and similar tags into the "deprecated" bucket help a developer trying to write code to convert .doc or .xls to OOXML?  If he comes across one of those tags, he’s got to do *something* with it, right?  What happens to his translated pages if he just ignores it? "

    Mike, if you had read the announcement, you would have known that ECMA is not just proposing to deprecate these features.  It has documented what should be done with them, just as you have demanded!

  29. Mike Brown says:

    @Ian,

    >> Mike, if you had read the announcement …

    >> it has documented what should be done

    >> with them, just as you have demanded!

    Okay, hands up; I skipped through the announcement and missed the Conformance section.  That will teach me!

    However, it still reads more like something than they’re going to do, rather than they’ve already done.  As my hypothetical doc->OOXML translation author, I’m still none the wiser on how to approach this.  (I guess any examples, should they exist, would still be under ISO restrictions at present).

    Cheers,

    – Mike

  30. Ian Easson says:

    Mike,

    I guess you, like all the rest of us, are going to have to wait a few weeks to see what they propose.

  31. Mike Brown says:

    @Ian

    >> I guess you, like all the rest of us, are going

    >> to have to wait a few weeks to see what they propose

    Indeed.  Although I still maintain that I (still with my hypothetical file format translator’s hat on) shouldn’t have to do so, and neither should anybody else.  Issues of this magnitude – specifically, the date bugs – should have been sorted out a *long* time ago; i.e, in the Ecma review, and not weeks before a fast track final BRM.

    Another question that I have – and again, I guess we’ll have to wait on this one – is whether Microsoft itself  will follow these new rules for conformance.  I mean, Office 2007 is already doing something when it encounters tags like AutoSpaceLikeWord95.  Will it carry on doing that, or will it change to follow Ecma’s new Conformance guidelines?

    Anyway, it’s early evening Christmas Eve here, and I’ve already had a couple of beers.  So, I’m signing off before I say anything (else) stupid!

    Cheers and Merry Christmas to you all.

    – Mike

  32. S says:

    hal said "You have a warped view. In 2004 the ‘ODF’ format was still called the OpenOffice XML formats and being developed by the Open Office XML TC in OASIS. So purely OpenOffice still."

    Interestingly enough, your constant quibble on useless matters always conveniently sidesteps the important issues. Here is one.

    Ever since Microsoft shipped a version of Office after Office 97, they produced a different and incompatible version of XML output. And guess what, Microsoft believes so little in XML that they never bothered to make it possible for you to migrate a flavor of XML into another flavor of XML (for instance Word 2003 to Word 2007) without their own products. They could have made it possible either with a compatibility SDK, or made it easy thanks to the XML itself (after all, that’s what XML is for). What you have to do is to run Office, load that XML in memory (binary representation), and save it into that other XML flavor. Once again, those mapping tables are key to the process, and Microsoft hasn’t made them public.

    Huh!

  33. S says:

    Mike said "the date bugs – should have been sorted out a *long* time ago; i.e, in the Ecma review, and not weeks before a fast track final BRM."

    That was sorted out in Excel 2003. The XML output has ISO 8601 dates. Only in Excel 2007, Microsoft changed their mind and went back to the old dates.

  34. Bruno says:

    What we are seeing is anti-OOXML people terrified that ECMA will actually succeed in addressing all of the "issues" that were raised, so now they are trying to move the goalposts.  The original strategy was to file so many objections that it would be impossible to address them all in time for the BRM.  But it looks like that strategy is headed for utter failure.  Not only is it headed to failure, it’s resulting in an OOXML spec that completely blows away the ODF spec in quality.  

    ODF was examined as a 1.0 spec, and therefore allowed to be ratified by ISO with the understanding that problems would be addressed in 1.1, 1.2, 2.0, etc.  But OOXML was given no quarter at all, and the result will be that ISO OOXML 1.0 will actually be of 1.1 or even 2.0 quality, which will make ODF 1.0 look silly by comparison.  ISO ODF 1.0 is missing pieces of very basic functionality, while ISO OOXML 1.0 will not only be feature complete, but polished as well.

    And that is the delicious irony, and it’s what Miguel predicted.

  35. Dave Lane says:

    Hi Bruno,

    Yes, ironic all right.  Even more ironic will be the fact that Microsoft has no plans to adhere to the spec.  Even if they could (and I don’t believe they’re capable of it).  I’d love them to prove me wrong.  But far far more, I’d dearly love them to drop OOXML and simply work with OASIS to improve ODF.

    Merry Christmas (just home from post Xmas lunch swim at the beach.  Gotta love the southern hemisphere 🙂 )

    Dave

  36. Karla says:

    Brian said "Years ago people thought that the binary formats gave Office some kind of competetive advantage because issues around the availability of the documentation or the ease of use."

    Today people think that Open XML aka DocX is a broken spec. The spec should not get fixed in a fast-track process cause fast-track is the wrong procedure for standard development.

    Your lock-in on your Office2007 implementation platform as the central argument while the standard gets it wrong. That is not only weak but incompatible with the objectives of ISO standards.

    "Not only is it headed to failure, it’s resulting in an OOXML spec that completely blows away the ODF spec in quality."

    The main problems are patent licensing conditions. All spec issues are just silly mistakes that ECMA made as it rubberstamped the spec. But in the ISO process we cannot address the patent problems. Therefore we need to file spec issues and ensure that we get enough poison pills to break the Microsoft spec.

    Please keep in mind that this is just the beginning of the war. You get your broken spec repaired and adopted (unless we stop it with an XML patent), but then the real battle starts. We will get more Open Standards regulation and ODF adoption by governments worldwide. In some nations you would succeed, sure. We will use all means of attack against your company and your format in order to slaughter your cash cow and break us finally free from your colonialism, i.e. interference into public poliy making of sovereign nations.

  37. Ian Easson says:

    Dave Lane, with the supreme confidence of the ignornant, wrote "Even more ironic will be the fact that Microsoft has no plans to adhere to the spec."

    Karla, self-wounded with hate, wrote "..this is just the beginning of the war. You get your broken spec repaired and adopted (unless we stop it with an XML patent), but then the real battle starts. We will get more Open Standards regulation and ODF adoption by governments worldwide."

    Hark, I hear the sound of goalposts moving!!

  38. Dave Lane says:

    Ian,

    Sounds like you’re much better connected than I am, Ian.  How are you able to explain your apparently boundless trust in Microsoft.  That they won’t "shift the goalposts" themselves on those who might strive for humble goal of interoperability.  Dude, have you been under a rock?  Perhaps you can explain your deep insight in to the mind of the behemoth?

    My "ignorance" is based on watching the behaviour of a convicted criminal monopolist (in several large jurisdictions in the world.  There’s no reason to think their illegal activities didn’t transgress laws in other jurisdictions, just that they weren’t brought to justice) like a hawk for the past 15 or so years, since I finished a thesis using Microsoft Word (a mistake I’d never make again, I might add) right across the lake from Big Bill’s massive bunker/house in Seattle.  

    If you can point out situations where Microsoft "did the right thing" in the past (and, just to clarify, by "right thing" I mean morally/ethically right, not "go to *any* lengths to maximise ‘shareholder value’ including selling soul to devil if it’s more profitable"), then perhaps I would gracefully accept the aspersions you cast.  As it stands however, from my perspective, your comment is touchingly naive, but ultimately unsupportable by precedent.

    Your mention of goalposts reminds me of the scourge of "tactical fouling" in professional sport. Unsportsman-like behaviour, isn’t it?   Yet, that’s exactly how Microsoft behaves in the business world – it wins games unless you get pulled up by the ref.  Of course, if you stoop to tactical fouling, you’re corrupting the whole process…  Luckily we never see that sort of behaviour in ISO votes, eh.

    Dave

  39. hAl says:

    @karla

    [quote]The main problems are patent licensing conditions[/quote]

    Strange because apperantly ISO and IEC ceo’s have examined the patent licensing conditions (= the OSP) and found no outstanding problems with it.

    Source: http://www.jtc1sc34.org/repository/0932.htm

    But I guess you are more knowledgable than ISO en IEC ceo’s on patent matters ?

    If so could you please show me some kind of example document that you can make using ODF licensing conditions but are unable to make using OOXML patent licensing conditions.

    Because I have heard tons of people cry about licensing conditions but they seem unable to produce something concrete they are not allowed to do with that licensing.

  40. Reggie says:

    If you don’t work for Microsoft, it’s probably not wise for you to say what Microsoft does or does not plan to do (like adhere to the spec). It makes you look like an idiot consipiracy theorist (but then again, you probably are if you think you’re smart enough to speculate about that.)

  41. Ian Easson says:

    For Dave Lane to suggest that Microsoft plans to not follow the revised spec is in fact for him to actually act like an idiot conspiracy theorist.

    There are two reasons:

    – For Microsoft to abandon OOXML after all they have done to get it established is completely contrary to their business interest.  Charitably, it looks like Dave Lane needs to take a basic business course.

    – It is contrary to how Microsoft *actually* already acted when confronted with the identical situation with the ECMA.  As any of the hundreds of thousands of Office 2007 beta testers knows, Microsoft had to issue a second beta because  the OOXML file spec changed (in ways that changed the actual formats).  Why was the spec changed?  Because after Microsoft had been persuaded to hand over control of the OOXML format to the ECMA commitee, that committee decided to improve the OOXML format.  Microsoft then had to put its Office 2007 developers in overdrive to implement the changes so they could issue the second beta.(For proof of the statements about ECMA, check the ERCMA site and the blorg of the ex-ECMA chairman; for proof of Microsoft’s response to the format change, see Brian’s older blog entry on this.)

  42. Dave Lane says:

    Hello Ian,

    I appreciate your concern for my education.  As for "idiot conspiracy theory", a quick Google search for "embrace extend extinguish" turns up about 18,000 hits.  The first page of results are all about Microsoft practices.  A nice bit of branding by Microsoft, eh?  Looks like conspiracy theorists have a lot of precedent on which to base their crazy ideas, don’t you think, Ian?    

    The only new twist in the MSOXML (it’s not open, so I don’t use the other O) process is that MS are trying to turn it into a standard so they can hijack it rather than embracing someone else’s (e.g. ODF), as apparently that would result in them losing their monopoly.  

    Needless to say, if you are aware of a little site called Groklaw, you’d know that I’m hardly alone in my mistrust of Microsoft’s motives and practices.  Looks like the US and EU governments, among others, share my concern.

    If Microsoft wants to gain trust, they’ll have to earn it slowly and painfully, because they’ve earned only scorn up until now.  

    Some relevant links:

    http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

    http://news.bbc.co.uk/1/hi/technology/6291124.stm

    http://www.groklaw.net/article.php?story=20051129101457378

    http://www.ddj.com/184404225

    http://news.zdnet.com/2100-9595_22-512681.html?legacy=zdnn

    All the best folks,

    Dave

  43. Ian Easson says:

    You neatly ignored all that I said.

  44. F says:

    Dave,

    So other than the Kerberos incident where an extension to Kerberos was done (which was eventually documented in 2002 on a published RFC) do you have any other references?

    Although the term "Embrace and Extend" has caught like wild fire, the article on the wikipedia is very mild.   There is the ActiveX vs Plugins discussion, but that was the choice between two vendor-specific platforms at the time (Netscape was as corporate as the time as Microsoft).

    Then there is the Kerberos issue which eventually got documented (2002, in an RFC) and which is also relatively mild.  Microsoft used a "Vendor-specific" tag that was part of the original specification to add their own vendor-specific features.   Sure, third parties could not interop, but that could be said about anyone using the Vendor-specific extensions built into the protocol itself.

    And finally there is a reference to J/Direct and the JNI in the Java wars.   In hindsight, we now know that J/Direct was a better technology than JNI and in fact a lot more portable.  

    So other than this, what do you have?

  45. Dave Lane says:

    This appears to be a somewhat more comprehensive list.  And these are just the ones about which people have taken the time to write…

    http://www.grokdoc.net/index.php/Dirty_Tricks_history

    You can try to excuse Microsoft’s antisocial behaviour with bland adjectives like "mild" but frankly, Ian, you’re sounding a lot like a Microsoft apologist.  You own much Microsoft stock?  

    Cheers,

    Dave

  46. Dave,

    "Even more ironic will be the fact that Microsoft has no plans to adhere to the spec."

    I think you are seeing it the wrong way. I actually think Microsoft (and others) will use "OOXML compliance" as a market-entry/perservation-mechanism and major selling point. As you propably know more and more governments are mandating usage of open document formats like OOXML and ODF and some of them (including the Danish government) are also demanding usage of specific versions. A lot of governments are also hesitant to upgrade the existing Microsoft Office 2003 install base to Microsoft Office 2007 and having Microsoft making O2007 non-OOXML-compliant will not make any upgrade-decision any easier.

    I might be wrong, but I don’t see any reason for Microsoft not to be OOXML-compliant in their product line. It would only drive more customers in the arms of OpenOffice or Lotus Notes if Microsoft cannot verify that their products are compliant.

    However – compliance it actually interesting in itself – because the ISO-system actually moves pretty slow and much slower than any development of either ODF or OOXML. So the dilemma you have as product manufacturer is – which version should you implement? Should it be the ISO-approved version or the latest-and-greatest non-ISO-approved version? OpenOffice apparently opened the last door and as far as I can see from the OpenOffice 3.0 feature list (http://wiki.services.openoffice.org/wiki/Features) it will use the ODF 1.2 specification as document format with code freeze in July 2008. I think it is very unlikely that ODF 1.2 will be ISO-approved by then.

    Of course, OpenOffice is in exactly the same position Microsoft will be in when OOXML is ISO-approved.

    :o)

    /Jesper

  47. F says:

    Dave,

    You seem to be attacking the messenger, rather than the argument.  

    I do not own any Microsoft stock (at least directly, maybe my bank reinvests through some fund in them).

    But am a happy Intel, Google, Vmware and Apple stock holder, and although an uneducated investor, all of those stocks have performed great for me.   Even as an uneducated stock investor it does not seem like the nearly flat Microsoft stock for the past few years was worth investing on, so I decided to not take the risk with it.  

    Of course, now that you point me to it, it seems that investing in January, August and April would have been great times to invest and get a nice 30% return.  

    I will read your link to Groklaw, but considering all the half-facts and lies in the opening section regarding OOXML, I do not have great expectations for it.

    F

  48. Racer X says:

    That Dave had to resort to Groklaw to prove his point shows how weak his point really is.  how about a source that has some credibility outside the "Microsoft is run by Satan" crowd?

    But I like how the anti-OOXML crowd is going wildly off topic with "Embrace and Extend" and the like (which in itself is ironic, since this same crowd actually advocated that Microsoft embrace ODF and extend it to handle MSO’s featureset), when the issue at hand is that ECMA is making steady progress on the OOXML spec, removing each of the objections that were filed, one by one, so that by the time BRM comes around, those that voted "NO" will have no valid reason to justify still voting "NO", and will be compelled to vote "YES".  I think of all the celebration that OOXML haters engaged in a couple months ago, and laugh.

    He who laughs last, …

  49. Dave Lane says:

    First they laugh at you… 🙂

    Frankly, fellas, if you’re looking to call into question the credibility of any entity (e.g. Groklaw – you’ll note, however, that my link was to Grokdoc… but why sweat the details, eh?), look no further than Microsoft’s famous ‘Linux myths’ pages.  They’re all good for a laugh.  Since Microsoft has now taken them down (as they were becoming increasingly hard to defend and were getting a bit embarrassing) they’re available on this mirror for your convenience:

    http://www.biznix.org/whylinux/microsoft1.htm

    A previous poster’s point about Microsoft having no incentive to break their own standard is absolutely incorrect.

    Outlined below, for the benefit of those previous posters who seem to believe Microsoft capable of honourable behaviour, is my point:

    _The Problem_

    1.  Many institutions, local and national governments are recognising the very real spectre of a "digital dark age" caused by the widespread use of proprietary and largely unsupported file formats over the past 20+ years.  As these organisations exist in part to hold the people’s information for posterity and in perpetuity, they are scrambling to address this problem.  To do so, they are starting to mandate the use of "open standard" file formats, where the formats are documented and visible for anyone to implement without cost or possible penalty for patent infringement.

    2.  Microsoft’s software has been a substantial contributor (perhaps the largest) to the problems of data locked into proprietary format.  

    3.  Microsoft cannot, at present, comply with the requirement to support open standard file formats, at least not without serious sacrifices in data integrity.

    4.  ODF is made an industry open standard by the ISO.    Microsoft suddenly realise they’re completely exposed because a number of compelling software packages (available either for free or for a fraction of the cost of its cash cow, MS Office) support this ODF standard already.  They never believed that ODF would be a credible alternative so quickly (not the first time they underestimated open source to their detriment).

    5.  Microsoft have everything to lose if they are forced to support ODF as a native file format.  As a number of MS execs have famously stated in emails in the past, if MS loses control of their proprietary office file format lock-in, then Microsoft will crumble into a flaming heap.  If MS supports ODF as a native file format, then they will be

    a) legitimising ODF, and

    b) forced to compete on a level playing field with OpenOffice.org and other contenders on price/merit for the lucrative government/institutional market.  

    When governments trial OOo and realise that it’s a pretty even match to MS Office for almost all uses but is free of license fees, then they’ll switch wholesale.  Business will follow suit, since the problems with file incompatibilities will be minimal with OOo.    

    So, what’s a threatened monopoly to do?  Well, it’s like this:

    _The Solution_

    Some clever (if ethically challenged) person at Microsoft realised that ISO is primarily a "branding thing" – most people neither know nor care what "open" or "standard" really means.  Sure, there’re a few industry experts and pundits who’ll have to be squelched, but Microsoft’s got plenty of influence.  Everything will be fine if

    1.  Microsoft can achieve an ISO standard, while

    2.  retaining *effective* proprietary control of it.

    Microsoft have realised that by pushing things through the ISO standardisation process via the ECMA, they can take advantage of those little "details" that very few people will ever try to understand – and they can paint anyone taking them to task a feckless pedant.  So, if the ISO standardisation comes through, while Microsoft still retain the ability to control the MSOXML format through their agreements with the ECMA, then Microsoft can

    1.  comply with requirements to support an "open" file format – "look, Ma, the box says ISO approved!", and

    2.  retain effective (if not official) control of the file format (what does "deprecated" mean, Microsoft??),

    3.  without letting the ODF supporting world establish a foot hold.

    Good business, right? Well, yeah, if you’re happy to compromise your own ethics and take down the credibility of the ISO…

    _Conclusion_

    The reality is that Microsoft are very good at clouding the waters, and attempting to paint themselves as reasonable.  They excell at taking fairly cut and dry issues and figuring out how to swamp them with fine points and arcane details so that they can achieve their self-serving ends despite the fact that everyone knows they’ve manipulated the situation.  Microsoft have all the resources and motivation to perpetrate such activities regularly.  It’s just that that type of arrogant behaviour and unpunished injustice gets some people angry.   Angry to the point where they step outside their normal societal roles and get active.  

    And that activity is reflected in places like Groklaw (credited with almost single handedly destroying SCO’s case against IBM and Novell) where people who care can make evidence available.  That evidence will eventually lead to justice.   Just remember – it’s all Microsoft’s to lose and we’ve got everything to gain.

  50. S says:

    "I think of all the celebration that OOXML haters engaged in a couple months ago, and laugh."

    Can you point to such "OOXML haters" out there that have a convincing reason to believe that Microsoft ISO blitz will be rejected? I think not one serious person thinks that. We all know that Microsoft is spending an enormous amount of cash and lobbying to get this ratified because there are a lot of reasons for them to do so. There are indeed implications in what Microsoft lobbies for. For instance, in my country, it’s hard to pass a week without reading articles about Microsoft sponsoring this, Microsoft sponsoring that, Microsoft giving cash to this, Microsoft giving cash to that. You think they do this for nothing? You don’t think Microsoft does this to get the vote they want, and that goes well beyond ISO and Office file formats ?

    As for "ECMA is making steady progress on the OOXML spec, removing each of the objections that were filed, one by one", I guess you need to learn to read. VML, which was already called deprecate in earlier versions (there was a reminder in each section where VML was used), is now called…deprecate. Now that’s what I call a big change! The only reason we are talking about VML is due to Microsoft’s own incompetence in pushing their draft to ECMA with a proper implementation of DrawingML. Note the word "implementation", instead of the word "design". This only to add that the spec was written after what we now know as Office 2007 was done, therefore it’s completely single sided and pushed by one vendor. For the exact same reason, people out there will laugh when they see that the next version after Office 2007 will come (most probably) with no use of VML anymore, which means all this deprecation in the ECMA paper was just nonsense from the beginning. This is what should be laughed at. This is what those Microsoft bunnies are doing in a standards org are doing that is laughable. Not the outcome, since we know what will be the outcome in february.

  51. Rick Jelliffe says:

    S: Living formats always have bits of history that  are going and bits of new things that are incomplete. It is just the nature of the beast. It is not "incompetence" to be living in one year rather than the next. VML in 2007, DrawingML in 2008, maybe SVG in 2010?

    What is unrealistic is to expect MS to have adopted an external format (ODF) through 2005 before it was actually fully-baked (2006? 2008?) or that standards means the end of history somehow: if we waited 10 more years and then standardized OOXML it would look pretty different again than now, I expect.

    So the issue for standards is how to promote the kinds of modularity that will allow the kinds of changes and consolidation (and plurality! too) so that ultimately technical concerns (good-market issues) not barriers (bad-market issues) drive the evolution of document formats.

  52. S says:

    Jelliffe said "What is unrealistic is to expect MS to have adopted an external format (ODF) through 2005 before it was actually fully-baked (2006? 2008?) or that standards means the end of history somehow"

    I’m curious to know how much Microsoft pays you for words of passion like this.

    That’s ridiculous.

    You are saying that it makes sense that a 1.0 spec contains deprecated sections.

    Really? Isn’t it the kind of thing you end up with after years of revisions, and broad adoption?

    Jelliffe said "if we waited 10 more years and then standardized OOXML it would look pretty different again than now, I expect."

    You conveniently side the issue again. This spec was written AFTER Office 2007 was done. It’s not ongoing work done openly.

    And, at the risk of repeating myself, VML should have never been part of this thing. It is only because Microsoft Office people have never managed to do one thing fully in a single release that we end up like this. If you go back to features introduced in previous Office versions, you’ll realize that this is quite a common theme : they never do things right in one release, it usually takes two or three releases to get things proper.

    In other words, what we should agree on right now is that this specs was rushed, that it should have never been allowed to go that far in the ISO process (with ECMA fucked both ways to just get the specs fast-tracked, unless ECMA is fully aware of that and actually an active collaborator of the Microsoft regime), that it should go back to the draft status until Microsoft can come up with something that really benefits everyone. I’m not against what Microsoft does per se. Here though, it’s obvious that it’s just self-serving : the lack of mapping tables in a migration format just means that it excludes any other product than Office 2007 to actually reliably support said migration features. I think it’s not too hard to understand.

  53. hAl says:

    [quote]VML in 2007, DrawingML in 2008, maybe SVG in 2010?[/quote]

    That would seem unlikely as SVG has limitations that even ODF cannot work with. ODF uses actually 3 sets of drawing namespaces. Only one of the 3 contains svg compatible tags but the other two contains openoffice related drawing features.

    Strangely enough where OOXML has superseded VML by DrawingML to be able to use more features OASIS for ODF has borrowed parts from SVG and then amended them with OOo drawing features (which is something that if OOXML would have done would be referred to as embrace, extend and extinguish…)

  54. S says:

    "VML in 2007, DrawingML in 2008, maybe SVG in 2010?"

    To rush and fast-track a standard that is not ready isn’t a contradiction?

    As for Microsoft supporting SVG, here is the rationale that was given when the team at Microsoft who built XAML after shamelessly stealing 99% of SVG principles, ideas and markup, said that "we choose to go with an object model that more closely matches what we think our users expect" and "While we share a rendering model with SVG to a large extent, our support and features don’t match up completely."

    With rationales like this, and just to be clear, nothing that can’t be fixed by revising SVG, something that clearly Microsoft opted out for some reason (hint: DirectX), you can indeed feel entitled the redefine just about everything, and go your own way about anything you fancy.

    Ok, but then what do ECMA and ISO have to do with this? ECMA and ISO are expected to discuss something that benefits people, not one vendor.

  55. S says:

    PS: here is the link to the "rationale" for using the proprietary XAML instead of SVG : http://www.eightypercent.net/Archive/2003/11/04.html#a153

    (Joe Beda was one of the key people who helped build XAML, part of Microsoft WPF rendering library.

    Joe Beda’s words after he left Microsoft, for Google : From the outside, I’ve also been able to look at Microsoft with different eyes.  What I used to rationalize away now appears absurd on the face. http://www.eightypercent.net/Archive/2005/09/04.html)

  56. Tom Mann says:

    D’oh! I don’t see the spec changing seeing as you’ve

    already

    implemented

    it!

    What you should be doing is finding a way to emulate these switches with several lines of already existing XML code. That way no other vendor has to worry about emulating

    AutoSpaceLikeWord95

    (Let’s face it, as long as it’s in the spec it’s an issue for anyone wanting to write compatible software)

    Also – Microsoft are banging onto free vendors about stepping on their IP. Is AutoSpaceLikeWord95 your IP? We’ll all have to assume so.

    OOXML is damaged until crap like AutoSpaceLikeWord95 is written out.

  57. hAl says:

    @S

    Basics is

    * SVG is a only a 2D spec

    * MathML does not support mixing with other Office tags.

    Such issues are unsolvable unles W3C does a quick feature extend of those standards and so even ODF does not use w3c SVG for that matter but instead uses OpenOffice:draw and OpenOffice:svg-compatible

  58. Dave Lane says:

    Frankly, fellas, if you’re looking to call into question the credibility of any entity (e.g. Groklaw – you’ll note, however, that my link was to Grokdoc… but why sweat the details, eh?), look no further than Microsoft’s famous ‘Linux myths’ pages.  They’re all good for a laugh.  Since Microsoft has now taken them down (as they were becoming increasingly hard to defend and were getting a bit embarrassing) they’re available on this mirror for your convenience:

    http://www.biznix.org/whylinux/microsoft1.htm

  59. S says:

    @Dave Lane,

    You are off-topic. If your point is to post general rants about Microsoft, I think you are wasting everyone’s time. We want on-topic arguments. Thanks.

  60. Chef Boyardee says:

    Wow, did Karla just threaten to use patents to stop OOXML?

    "Please keep in mind that this is just the beginning of the war. You get your broken spec repaired and adopted (unless we stop it with an XML patent), but then the real battle starts. "

    Then she goes on to other tactics on how to stop OOXML.  

    In this debate, technical merits, since the beginning have not been much of an issue.   There were certainly some problems, but nothing major and with elements documented like "autoPartyLikeIts99" the attack on technical grounds seems to be loosing some of its impetus.

    Sadly, this seems like its going to be another year packed with rhetoric from the anti-OOXML crowd.

    Hopefully, with the technical issues lifted, the politics will hopefully vanish and this standard will become as fascinating as watching water boil.  

    Which is where this standard belongs (boring to read, but useful as reference).  And for that matter, every single other XML standard is in the same category.   In fact, reading *any* XML standard before bed time will eliminate the worst of your insomnias.

  61. Ian Easson says:

    When all the dust settles in a year or so, someone should collect some of the more "interesting" comments and predictions by the anti-OOXML folks, and compare them with what reality turned out to be.

  62. dmahugh says:

    Great minds, Ian. the list is growing. 🙂

  63. Sesam says:

    > And for that matter, every single other XML standard is in the same category.   In fact, reading *any* XML standard before bed time will eliminate the worst of your insomnias.

    We did and decided to don’t invest time into MSOOXML cause it’s not ready yet compared to ODF. Maybe 2009.

  64. Sesam,

    "We did and decided to don’t invest time into MSOOXML cause it’s not ready yet compared to ODF. Maybe 2009."

    I congratulate you on excersizing your ability to have what a lot of us want with respect to document formats: The ability to choose the format that best fits our needs and not have a single format chosen for us.

    :o)

    /Jesper