Slashdot Mirror
Microsoft Deprecating Some OOXML Functionality
christian.einfeldt writes "According to open standards advocate Russell Ossendryver, Microsoft will be deprecating certain functionality in its Microsoft Office Open XML specification. Ossendryver says the move is an attempt to quiet critics of the specification in the run up to the crucial February ISO vote. The Microsoft-led industry standards group formally offering OOXML confirms in a 21 December 2007 announcement that issues related to the 'leap year bug', VML, compatibility settings such as 'AutoSpaceLikeWord95' and others will be 'extracted from the main specification and relocated to an independent annex in DIS 29500 for deprecated functionality.'"
If MS deprecates it but makes support for the deprecated features the default option in their software, they'll still be contributing to people spewing incompatible files that don't render correctly in software following the standards. It'd be better to just rip out the parts that shouldn't be there and resubmit the standard. Having to recognize and either support or report lack of support for a maze of twisty little semi-standard features for sake of backwards compatibility is not going to help the situation much,
It's abundantly clear now that the format is critically flawed and cannot be implemented by anyone, not even the Office team themselves.
ECMA 376 is a bomb disguised as a standard. It redefines functions and components just to retain ties to the undocumented legacy formats. Therefore a number of things that should be fixed by now, thanks to better engineering, and existing ISO standards, are left not only unfixed, but even perpetuated by ECMA376. The fact that Microsoft continues to push this fake "standard" shows how little they care about their customers and how much their business is predicated on lockin."I've got more toys than Teruhisa Kitahara."
In another move to spread more FUD, now they're trying to hide the UGLY part of the specification. But, what use is hiding it? They claim the deprecated features will be used only for the migration of old binary formats, and that they should not be used by new documents... But considering that the whole point of this document format standardization effort is to be able to open any document in 20 or 30 years time, and if the old binary format documents will be converted using deprecated features, that just means that any software implementing the standard will have to support the deprecated features anyway...
Although they keep manipulating, manipulating, and manipulating more, I still think their format stinks, they're only using it to spread FUD over other formats, and I really hope they can't pull this stunt.
Just like with Vista, they just drop features until it's "releasable."
Here's the obvious problem:
They will claim a feature is deprecated, or not part of the spec, but their software will continue using it. Meanwhile, other programs that try to read and write OOXML format following the "official" spec, will result in the documents created or edited by other programs not being fully compatible with MS Word. This will be seen by the user community as a deficiency in the alternative software and no as a problem with Microsoft's software.
We have seen this before and we continue to see it. People think that because a web site works with MSIE and doesn't work with Firefox that there's a problem with Firefox... Microsoft continues to damage the competition in this way and will persist in the same. I hope that the voters in the ISO decisions are aware of this potential problem.
This seems sneaky to me. Remove controvesial stuff from the standard, but put it in an Annex, that MS will implement and people will rely upon left and right, so it will become a de-facto microsoft embrace-and-extend standard.
I really try to fight the kneejerk anti-microsoft sentiment around here, but lordy, all of their moves seem so calculated and evil. It's not just single actions, it's a pattern of actions. Humans are great at recognizing patterns. And even with good moves and bad moves, one can generally see a positive attitude behind Google, for example (some may disagree, but I think the general consensus is that they're not dastardly.) But with MS, every move seems like a piece of a puzzle showing a nasty, calculated, aggressive, anti-competitive entity. Everything seems consistent with that. The way the US rolled over on everything for political reasons is shameful. Hopefully the EU will right some of those wrongs, at least in part of the world.
I guess to try and find the bright side, one could say "at least it's documented" (without an exorbitant fee and crazy restrictions, like SMB et al.)
Love many, trust a few, do harm to none.
"Deprecate" is also technology jargon that means "to mark as obsolete." How you could be a Slashdot reader and not be familiar with that usage, I cannot understand.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
The stated goal is to create a standard compatible with a single vendor's single product. I'd say that alone disqualifies it as a standard. Even if they change the wording, they would have to explain why they included this verbiage in the first place. Note the rewording under the Goal:
Two things. The goal mentioned in the introduction is reworded from "existing investments in Microsoft Office documents" to "existing files and applications", which sounds more interoperable but it really isn't. Also, by meeting this goal, this standard benefits.... drumroll... people who are forced to use Open XML. This goal could be achieved simply by using the standard proposal as documentation of the file format, and forgo the whole OOXML standard because its stated goal has already been achieved.
To summarize: unless there are other unstated (hidden) goals, which most likely would benefit Microsoft, there is no outside benefit to having this be a standard. If there are other, more beneficial goals, they should be discovered and listed.
If the goal truly is to "support and strengthen document archival and preservation", it would make more sense not to just deprecate AutoSpaceLikeWord95 or the other black box definitions, but to actually create definitions which specify the exact behavior, as has been noted elsewhere. Otherwise the standard does not meet its own stated goal. And an added benefit would be to wrap this spacing definition in some sort of grouping to show that these measurements and behaviors are all one entity - in other words, if you remove or ignore this spacing information, you should do it as a group, not just ignoring one part of it because your application does not implement that section. There is simply no way to "support and strengthen document archival and preservation" by leaving such definitions undefined. That is exactly the opposite of its stated goal.
One other part that bothers me is "in a way that fosters broad and innovative use of the Office Open XML file format". Not for convenience or clarity, but to make more people use the Microsoft format. In other words lock-in, or the transition between embrace and extend.
The only reason that ODF cannot be a direct replacement for OOXML, and why ODF cannot serve to achieve the stated goals for OOXML, is that ODF does not support some of the features of Of
Aside form the above and a few other things, it's a great standard... </sarcasm>
Now -- would you care to tell us who you are and who you actually work for "Anonymous"?
The contest for ages has been to rescue liberty from the grasp of executive power. -- Daniel Webster