California Joins Open Document Bandwagon

Andy Updegrove writes "A legislator in California has decided that it's time for California to get on the open formats bandwagon. If all of the bills filed in the last few weeks pass, California, Texas, and Minnesota will all require, in near-identical language, that 'all documents, including, but not limited to, text, spreadsheets, and presentations, produced by any state agency shall be created, exchanged, and preserved in an open extensible markup language-based, XML-based file format.' What type of formats will qualify? Again, the language is very uniform (the following is from the California statute): 'When deciding how to implement this section, the department in its evaluation of open, XML-based file formats shall consider all of the following features: (1) Interoperable among diverse internal and external platforms and applications; (2) Fully published and available royalty-free; (3) Implemented by multiple vendors; (4) Controlled by an open industry organization with a well-defined inclusive process for evolution of the standard.'"

Comments

Woohoo, ODF soon to be here

[guruevi]

I think the only document format that would qualify is ODF (by OASIS). It's the only well known document format, based on XML and extensible, open and implemented by different vendors and office suites.

American legislation 101

[bornbitter]

"Why do lawmakers always have to over-specify things until the purpose of the law is lost?"

          This is over-simplified, but here goes... American laws are made in sub-committees of committees of the legislative body. The committees are packed with 'specialized' delegates, i.e. someone with a political stake or in the pocket of a special interest group, (like Microsoft, OSDL, or Green Peace). ...of course that is the federal process, and the states vary in their organization, but it is mostly the same. It all depends on how the states have drawn-up the rules for their specific legislature.
          Keeping that in mind, every law has to 'pass' through the upper committee after the sub-committee, before passing in the full-legislative body. The extra wordiness is to satisfy the other 'specialized' delegates' demands.
          To put it simply; They HAVE to make it ridiculously wordy or it will never become a law. There is just too much money involved. This means that all Microsoft, or anyone else, has to do is 'buy' an influential delegate in the sub-committee, or the chair of the committee in order to kill this bill before it is even voted on in the full legislature.

Re:Text in XML?

[hey!]

Well, obviously it doesn't need to be xml, but XML does have one nice self-documentation property that plain text lacks: the character encoding.

If you've looked at project gutenberg texts, you can see why this is a problem. Not a huge problem, but a problem. When a source text has a non-ascii character in it, they have to put some sequence of ascii characters which will suggest what the glyph is supposed to be. This doesn't really preserve the information in the source document, nor does it make the document easy to read.

So, you could have a trivial text XML format that has only one defined tag. It's still useful:
<xml version="1.0"? encoding="us-ascii">
<text>
This is my text. It has no wacky glyphs so ASCII is fine.
</text>

vs.

<?xml version="1.0"? encoding="utf8">
<text>
This is my text. It has wacky glyphs therefôre ascii sücks for it!
</text>

Oh Please!

[Anonymous Coward]

There is one particular spreadsheet we have to email for a report - it is loaded with Active-X controls and the like, it Works with Excel on Windows and nothing else. One of the insances where we have to pull out 'the Windows laptop' to do the report once a month.

But since that is a reporting metod with contractors (not the general public), I bet it would be an exception.

Along with that there are other Windows specific gotchas - one is an the Access DB that another program has required us to use, and the third instance, a reporting site that is loaded with IE specific ActiveX code (even if you spoofed as IE, it doesn't work).

Every other state report we do sanely accepts either a, delimited text uploads, plain old paper reports, or a 'most browser friendly' web form.

Re:Minnesota also

[foniksonik]

If it is an open XML based format then doing a conversion to whatever new format arises should be trivial (maybe not fast, but fairly easy with XSLT). SO better to put it into XML now and worry about what better format may arise later.

This is good news... why be negative about it?

Re:Criteria n3

[Coryoth]

In other news, Microsoft is quickly subsidizing 3 small companies to write quick and meaningless stupid plug-ins using OOXML as input, just to pretend that their format is "Implemented by multiple vendors" and on "diverse (...) platforms" (ie.: Windows 98, Windows ME, Windows 2000, Windows XP *and* Windows Vista)... I think MS may actually have already squeezed through this particular hole. The reality is that other vendors are going to have to be able to read and write OOXML at a basic level for compatability. They'll never fully implement the standard that MS has written because they can't possibly implement the behaviour of the <SpaceLikeWord95> tag and all the others like it, but they'll have something. If you demand a "full" implementation from multiple vendors you're just digging yourself a different hole: nothing will qualify. Honestly, try reading and writing .odf files in a few different products (OpenOffice.org, KOffice, AbiWord, Writely, etc.) and you'll find the formatting gets noticeably messed around. Fully implementing ODF might be more feasible than fully implementing OOXML, but that doesn't mean it will actually happen. It seems MS has managed an effective pre-emptive strike against such legislation - they've created a "standard" that is just open enough to qualify, but sufficiently obscured that no one else can actually claim full compatability - the kicker being that full compatability is unlikely with any sufficiently complicated standard (as standard for office documents are bound to be) so you can't specify that as a criterion.

Two Possible Outcomes

[BCMcI]

If California passes this resolution I can see two outcomes. 1 The state recognizes that ODF has to be used and scraps Office and loads OpenOffice or StarOffice. Big win for the citizens of California big loss for Microsoft. 2 The state recognizes that ODF has to be used and because older versions of Office won't work with ODF they purchase Vista and Office 2007 for all state agencies. Huge loss for the citizens of California huge win for Microsoft. Guess which is more likely?

In Completely Unrelated News...

[antirelic]

3 states who's yearly budget is under review are looking for ways to drive down existing IT costs by threatening to pass legislation that will get them huge discounts on Operating System and Office Software .........

Re:Microsoft's open XML format:

[atamyrat]

http://worsethanfailure.com/Articles/XML_vs_CSV__0 x3a__The_Choice_is_Obvious.aspx

Isn't quite the same situation

[DrYak]

It seems unlikely that KOffice is a complete superset of OpenOffice, therefore even if both OOo and KOffice implement ODF, KOffice can never be completely interoperable with OOo (at least OOo -> Koffice). Further, if KOffice implements any features that OOo doesn't have, then the same is true in reverse.

Although the starting situation is mortly similar with OOXML, it isn't quite exactly the same.
Yes, there may be some different way to interpret the standards, and maybe two different implementation produce slighlty different results (Spreadsheet formules, for exemple aren't standarized yet). The difference is that this standard is controlled by a whole comitee (OASIS), in which several software maker are represented, include FLOSS, and it's in their interest to have the best interoperability as possible.
Thus there's a high probability that, faced with such a situation, the detail of the implementation will be specified in next OpenDocument revision, so that the other software can do a better job in opening their interoperation. In fact, latest versions of AbiWord seem to be much more close to the original OpenOffice.org document. Or maybe they'll even create a new options that allows to tweak the parameters of the function in a documented way ( where 2.67 imitates best the behaviour of OOo and 3.14 is KOffice's default and 3.00 is what every new application is supposed to assume in case of missing param, according to documentation)
And if some other product develops more functionality than ODF is capable of encoding, there's a high probability than an extension will be written and published with the next ODF revision.

In fact, ODF isn't as much direct memory dump of OpenOffice.org as SXW was. ODF has been further processed by OASIS. Whereas OOXML (for now) is still a direct memory dump.
s the sole and unique maintainer of the OOXML specification, it's not in their interest to maintain pixel-perfect conversion for competitor (they need competitor to be bale to interoperate with document formats - to shut the people complaining up - but they need to be the only product that can promise 100% pixel-perfect imports).
Regarding with difference of working, the whole documentation is bloated with definition of options like "" for several thousand pages, which aren't explicitly documented at all (it's only written that they will be deprecated and that implementation aren't required to react to them). Only MS-Office will ever be able to open them by definition (Abiword may be able to reverse engeneer them, but it'll take more work than asking OASIS for a better documentation).
You can bet that, if Microsoft adds some new functionality, they'll be the only one to support them as a paid-for extension... probably called 'Visual OOXML#'. You can be sure that they'll out-"Embrace, Extend, Extinguish" their own ECMA approved standard.
Or at least to produce as badly written as possible documentation.

What will make the difference between OOXML and ODF is microsoft willingness to cooperate (or lack of), and OASIS comitee collective need to collaborate between members.
The only potential way to save OOXML is to put it into control of a groups, in which there's at least one FLOSS represented (say, WordView), which will have to grant full right to use and promise not to patent-sue independent implementations, and will force Microsoft to use OOXML instead of some "MS OOXML.net" extensions.
Which they'll never agree to.