Slashdot Mirror
New York and Minnesota Publish Open Document Studies
Multiple readers have written to point out that New York and Minnesota have reached the end of their lengthy deliberations on open document formats. Both reports agree that an open format would be beneficial, but neither were willing to endorse a particular choice. New York's executive summary notes, "The State Legislature should not mandate in statute the use of any specific document creation and preservation technologies, as technologies can easily become outdated." Minnesota's report claims, "The marketplace is still in flux, and it is not certain that a single standard will emerge." In related news, yesterday's announcement from Microsoft that they would provide support for ODF in a future update to Office 2007 has EU antitrust investigators optimistic, but cautious. Microsoft has said that the ISO process was what prevented OOXML from receiving support in the same time frame.
Legislation is difficult to change once passed. Competing interests (or lack of interests) and simple inertia mean that whatever gets written into law stays there for a while. It makes sense for the law to say that the standards should be open, that they should be chosen by a particular state agency, or that they should be reviewed every X years. But writing the choice of standards into law is very inflexible. There is a reason why we have building codes and highway codes. This doesn't say that administrative rulemaking is less subject to lobbying and corruption, or that it is more transparent. But on these counts it is no worse than primary legislation.
I think what the legislators were saying was
Other good news....
its a good year for document freedom.
- Joel
The current version of the ODF standard will become outdated because it will be superseded by a new, improved version. That is no reason against implementing the current version of the ODF standard now, because the other players in the Marketplace (now including Microsoft) are doing the same, and when the new version comes out, your investment in support for the current version is not lost. Rather, it enables your program to continue using documents in that version of the format, and to interoperate with other implementations of that version of the format.
By contrast, it looks likely that IT reality will completely ignore ISO/IEC IS 29500:2008 (the ISO standard for OOXML) because Microsoft has said publicly that they're not going to bother implementing any of the changes until "Office 14", so for the foreseeable future there isn't going to be anyone to interoperate with via that format. And when "Office 14" comes out, it'll certainly introduce further changes to the storage format. Therefore, why would anyone want to implement the current ISO version of OOXML? Inaction regarding that is totally justified!
More spin.
This statement is misleading. Every file written by OpenOffice.org, KOffice or IBM Symmphony (to use common examples) is ODF compliant. The file may not require every tag in the full specification to describe the contents each application is capable of writing, but it will comply with the standard.
In other words, each application is fully compliant with the subset of the standard mandated by the application's content creation role.
By contrast, MS Office does NOT write compliant OOXML files at all.
"I've got more toys than Teruhisa Kitahara."
They are talking about what's preventing *Microsoft* from supporting it in Office 2007. The problem for MS is that OOXML as submitted by MS, and OOXML as approved by ISO is not completely the same. There are minor incompatibilites, which would prevent Office 2007 SP n-1 from fully understanding documents written with Office 2007 SP n. Microsoft doesn't want this situation, they only want to introduce incompatibilities with new versions. At least with a new version, customers have learned to expect incompatible documents. So Office 14 will create OOXML documents that Office 2007 won't fully understand. Office 2007 SP n will not.
Question: How does a format really get out of date
There are several ways in which a format can become outdated. Below I will list some. You will notice that from a strictly technical point-of-view they aren't even close to being show stoppers (ie. you could work around them probably in several way). However, should that outdated format be mandated for use by a law then the technical challenges and financial burdens may become serious hindrances in the least and actual show stoppers in the worst case. Changing a law will always be more difficult than changing just a standard.
An ad hoc list of how a format can become outdated (pardon the poor examples):
1) An underlaying technology or medium becomes outdated. Example: 8-, 16-, and 32-bit integers. Another example: pre-web/xml EDI-formats.
2) A superior (= more fit) competing technology is developed. Example: SGML vs XML.
3) The intended use case of the format becomes outdated and/or irrelevant, which may happen due multitude of technical and non-technical reasons (the world does not stand still). Example: an early text-processing format that does not support hyperlinks or embedded pictures. Data formats for various deprecated ports.
Your particular question was about "an XML format designed to represent a wordprocessed document. How exactly is that going to go out of date?" Let's first note that in practical terms this is a format specifically designed for longevity. However, it fairly easy to imagine that a word processing format designed today does not allow for all important future use cases. Information about intention might be very important in mere twenty years, as AI and cognitive modeling applications might require it. The format might lack important security features that become necessary way you interface with data via a brain implant.
Computers are useless. They can only give you answers - Pablo Picasso
That hard (not to say impossible) for a *3rd party* to implement. BUT implementing it in MS-Office is easily done because, you know, the functionality is already here in the backward-compatibility code that hangs around somewhere in the big spaghetti mess. (In fact the criticism was that Microsoft just dumped their innerworking into a format instead of engineering an format which was actually build for exchange - whereas ODF has undergone quite a few modification since its early SXW days, in which the other player of OASIS had the possibility to take part).
The problem isn't there. The problem is in the small remaining part that actually looks like standard and was a little bit doctored by the ISO to really function as one. (Even if the whole process was fast tracked)
They end up with an ISO standard which is very similar but not exactly like what they have currently. This will force them to dig through all the big chunks of legacy code to fix the ISO improvements, but without breaking the backward compatibility (damaging the rest of the 6000+ bulk).
That's why they blame ISO for the delayed introduction of OOXML : "Oh,noes ! They've edited it ! Even if the ECMA rubber stamped it without question !! How dare they ??? Didn't we bribe them enough ?!? Now we won't be able to sell the software we already have as ISO OOXML compliant ! We'll have to edit it first !!".
That's also ODF makes sense for them : they "just" need it to implement it from scratch. It's non-trivial, but they don't have legacy code (worth 6000-pages) to wrestle, just a brand new implementation.
(As a side note: that's not only valid for OOXML. ODF was intensively reworked by the OASIS committee before being submitted as an ISO standart. And thus, OpenOffice had to implement it as a _separate_ input/output format instead of just relying on its classic SWX reader. The legacy staroffice xml format are still available as an alternate saving format).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]