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.'"
The criticism that OOXML is basically unnecessary for anyone other than microsoft still hasn't been adequately addressed. This is like microsoft proposing MicroMiles should be an international standard because they don't control the implementation of kilometers. They could have just contributed to ODF if they were remotely interested in useful standardisation, they were given ample opportunity.
The criticism that the standard may be patent-monopoly-encumbered hasn't been adequately addressed (but that is unfortunately pretty typical of "old" standards bodies like ISO and ECMA and ITU). Really, that's not OOXML-specific, far too many "standards" are unimplementable freely (free licensing should be a basic legal requirement for any national-government-recognised standards but isn't... yet. The baby boomers are trying to get as much corruption in as possible before they become decrepit and we take over and have to clean up their mess).
If you agree that this is a real risk, and you're willing to help with doing something about it, please join us at OpenISO.org and help put together a "problem report" document about OOXML that explains the main issues clearly.
The correct link is here: http://www.openmalaysiablog.com/2007/06/is-vml-in-or-ou.html
.htm instead of .htmnl; which results in a 404.
I see you have it as
Change is certain; progress is not obligatory.
+100.
Unfortunate reality is that M$ provides nearly complete (== always incomplete) solutions. Up side is that you can base your business on it. Down side - you are locked into M$ solutions. But you heard that hundred times already. But what everybody's missing is development side: developers working solely on M$ platforms turn slowly into agoraphobic drones who would claim that "M$ is best" just because they do not know anything better.
Many of my versity friends turned into such drones - even most reasonable ones. M$ keeps feeding them with new (presumably better) APIs and they just keep their minds piped directly into their beloved MSDN subscriptions. 5 (or 6?) data base APIs? And M$ still keep printing them. 6 IPC APIs? - OLE, OLE2, ActiveX, COM, DCOM, COM+ - but M$ doesn't stop the printing press.
"Windows is better because it has API [XXX] and [Linux/Mac OS X/etc] doesn't." Explaining people that API does solve Windows specific problem which doesn't exist on Linux nor Mac OS X just doesn't work - because they never touched them. And they will never touch them because they do not have the M$Windows' hundreds APIs. (Recent best example was ASIO - and fact that only Windows does support it.)
All hope abandon ye who enter here.