Freigeben über

500+ national body comments posting today

  • Artikel

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

  • Anonymous
    December 21, 2007
    The comment has been removed

  • Anonymous
    December 21, 2007
    "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.

  • Anonymous
    December 21, 2007
    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

  • Anonymous
    December 21, 2007
    Ecma TC45 has uploaded to their web site proposed dispositions for 2298 of the 3522 total DIS 29500 comments

  • Anonymous
    December 21, 2007
    Ecma TC45 has uploaded to their web site proposed dispositions for 2298 of the 3522 total DIS 29500 comments

  • Anonymous
    December 21, 2007
    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.

  • Anonymous
    December 21, 2007
    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.

  • Anonymous
    December 21, 2007
    S, you should take your paranoia to Groklaw.

  • Anonymous
    December 21, 2007
    @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).

  • Anonymous
    December 22, 2007
    @hAI, your comment is deprecated, you should it to an optional part of this blog.

  • Anonymous
    December 22, 2007
    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!!!

  • Anonymous
    December 22, 2007
    @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.

  • Anonymous
    December 22, 2007
    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.

  • Anonymous
    December 22, 2007
    @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.

  • Anonymous
    December 22, 2007
    The comment has been removed

  • Anonymous
    December 22, 2007
    The comment has been removed

  • Anonymous
    December 22, 2007
    >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

  • Anonymous
    December 22, 2007
    [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 )

  • Anonymous
    December 22, 2007
    @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.

  • Anonymous
    December 22, 2007
    @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".

  • Anonymous
    December 22, 2007
    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.

  • Anonymous
    December 23, 2007
    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.)

  • Anonymous
    December 23, 2007
    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.

  • Anonymous
    December 23, 2007
    >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

  • Anonymous
    December 23, 2007
    @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.  

  • Anonymous
    December 23, 2007
    The comment has been removed

  • Anonymous
    December 23, 2007
    The comment has been removed

  • Anonymous
    December 23, 2007
    The comment has been removed

  • Anonymous
    December 23, 2007
    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!

  • Anonymous
    December 23, 2007
    @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

  • Anonymous
    December 23, 2007
    Mike, I guess you, like all the rest of us, are going to have to wait a few weeks to see what they propose.

  • Anonymous
    December 23, 2007
    @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

  • Anonymous
    December 23, 2007
    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!

  • Anonymous
    December 23, 2007
    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.

  • Anonymous
    December 24, 2007
    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.

  • Anonymous
    December 24, 2007
    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

  • Anonymous
    December 24, 2007
    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.

  • Anonymous
    December 25, 2007
    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!!

  • Anonymous
    December 25, 2007
    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

  • Anonymous
    December 25, 2007
    @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.

  • Anonymous
    December 26, 2007
    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.)

  • Anonymous
    December 26, 2007
    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.)

  • Anonymous
    December 26, 2007
    The comment has been removed

  • Anonymous
    December 26, 2007
    You neatly ignored all that I said.

  • Anonymous
    December 26, 2007
    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?

  • Anonymous
    December 26, 2007
    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

  • Anonymous
    December 26, 2007
    The comment has been removed

  • Anonymous
    December 27, 2007
    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

  • Anonymous
    December 27, 2007
    The comment has been removed

  • Anonymous
    December 27, 2007
    The comment has been removed

  • Anonymous
    December 27, 2007
    The comment has been removed

  • Anonymous
    December 27, 2007
    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.

  • Anonymous
    December 27, 2007
    The comment has been removed

  • Anonymous
    December 27, 2007
    [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...)

  • Anonymous
    December 27, 2007
    "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.

  • Anonymous
    December 27, 2007
    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)

  • Anonymous
    December 27, 2007
    The comment has been removed

  • Anonymous
    December 28, 2007
    @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

  • Anonymous
    December 28, 2007
    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

  • Anonymous
    December 28, 2007
    @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.

  • Anonymous
    December 31, 2007
    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.

  • Anonymous
    December 31, 2007
    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.

  • Anonymous
    January 02, 2008
    Great minds, Ian. the list is growing. :-)

  • Anonymous
    January 02, 2008
    > 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.

  • Anonymous
    January 02, 2008
    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