12.27.07
OOXML Watch: Latest Articles Include ECMA’s New Tricks
Keeping an eye on the very latest…
Over at ZDNet, a new article covering OOXML has just been published.
“OOXML is philosophically a problem,” says StandardsNZ’s Jackson. “The world already had a standard [in ODF].”
“There has been insufficient technical rationale as to why we need another standard,” added open source advocate Jeff Waugh.
But Jelliffe insists that it is unexceptional for there to be multiple standards in document processing languages, just as there are in graphics, programming languages, schema languages, even screwdrivers.
In relation to Rob Weir’s recent essay on the ECMA-Microsoft bait-and-switch maneuver, noooxml.org has just published the following:
So what Ecma is offering SC34 is nothing close to what was promised. Ecma is really seeking to transfer to SC34 the responsibility of spending the next 3 years fixing errors in OOXML 1.0, while future versions of OOXML (“technical revisions”) are controlled by Microsoft, in Ecma, in a process without transparency, and as should now be obvious to all, without sufficient quality controls.
Here is the ECMA press release [via Andy Updegrove] which corresponds to a short article that we mentioned only a few days ago.
21 December 2007 – Ecma TC45 has been making continued progress on the comment review process, supporting the ISO/IEC DIS 29500 Project Editor’s mid-January deadline to deliver a comprehensive report of Ecma’s proposed dispositions.
[...]
b) Leap year calculation
ECMA-376, the original Open XML standard adopted by Ecma, treats 1900 as a leap year in order to maintain compatibility with earlier spreadsheet applications that included this error. This is an important compatibility consideration, but based on the comments received by many National Bodies on this issue, Ecma acknowledges that the date system should be correct. The newly defined date system described in the previous item treats 1900 correctly. The leap-year bug will be deprecated, as described in the next item.
2 Functionality extracted from the main specificationMany National Bodies identified specific functionality within the specification that reflected existing product defects or legacy application behaviors. These behaviors are important because they reflect the content in existing documents, but should not be perpetuated when creating new documents from scratch.
Deprecation as part of a newly-proposed ‘standard’ seems absurd. Of course, if a standard was to evolve, then deprecation can be expected, but herein, as you can hopefully see, it’s all broken before it was even born. Only in ECMA can such absurdity be seen as acceptable. The whole thing is sham. █
Content is available under CC-BY-SA