Slashdot Mirror
MN Bill Would Require Use of Open Data Formats
Andy Updegrove writes "A bill has been introduced in Minnesota that would require all Executive branch agencies to 'use open standards in situations where the other requirements of a project do not make it technically impossible to do this.' The text of the bill is focused specifically on 'open data formats.' While the amendment does not refer to open source software, the definition of 'open standards' that it contains would be conducive to open source implementations of open standards. The fact that such a bill has been introduced is significant in a number of respects. First, the debate over open formats will now be ongoing in two U.S. states rather than one. Second, if the bill is successful, the Minnesota CIO will be required to enforce a law requiring the use of open formats, rather than be forced to justify his or her authority to do so. Third, the size of the market share that can be won (or lost) depending upon a vendor's compliance with open standards will increase. And finally, if two states successfully adopt and implement open data format policies, other states will be more inclined to follow."
It is not hard to reverse engineer a proprietary format - several word processors can save in competitor's formats. So this is a symbolic gesture, but it will be good in the future when Microsoft and others copyright their file formats to try and extort money from OpenOffice.Org and others.
I don't think it's significant at all, Minnesota was closer to being red in the latest election than almost any time in the last century. It can all be directly attributed to the Twin Cities having a very tech-oriented community, often given titles such as "Most Wireless City" and other things. Outside Silicon Valley and Seattle, it is probably the most tech oriented metropolis. This would of course have an indirectly related effect on it's political orientation as well, but partison politics really seem insignifact cause-effect wise.
I trust Microsoft as far as I could comfortably spit a dead rat
That sounds pretty much like the same insults that were slung in my face umpteen years ago when I was trying to argue for using standardized formats for data in several projects.
Anyway, I find it sad that so few "programmers" actually bother learning anything about the history of what they are doing.
In "legacy programming" people pretty much saw data as separate from the program. In "legacy" programming you would generally go about a project in two steps. You would design the data format in one step and the program in another. In a project you would write and publish both documentation for the format and program.
The problem with this "legacy" design methodology was that you have to keep your published data formats in sync with all programs that access the data. Let's say I had a data store where the lastname was 24 characters. In release 1.17, I change the lastname to 32 characters. If someone else had written a program that was directly accessing and manipulating this data; we would have a crisis.
The bold statement of OO design was that the object owned the data. The object would have complete control of all data from start to finish. You would only publish the interface and not the data format (you would still write both documents, the latter would not be published). This ideal worked well in interface design, but fell flat when dealing with long lived objects saved to disk. Have you ever heard the phrase the "problem of persistence," or are you as ignorant as you are arrogant?
The problem of persistence was this horrible challenge for pure OO design. No matter how you went about it, data needs to be stored, replicated and transferred outside of the control of a single program. Anyway, many of the first OO programmers took the bold statement that the object owned the data to its logical conclusion. They ended up writing programs that saved data in terse, obfuscated, proprietary formats.
I know this happened because I was there with my little hexadecimal editor looking at the data.
OOP was never able to achieve the goal of a single object controlling long lived data. The OO world gradually dropped its bold statement. This is the way history works.
This long post is relevant to today's article because many OO languages still have objectStore methods that save the internal state of the object to disk. I suspect that any OO program using these object store methods are in violation of the MN law. Even though I dislike programs that store their data in bizarre formats, I don't like seeing them legislated out of existence.
Sun and other companies use XML for object persistence. These files are more readable, but still hard to work with.
Please note that I was talking about publication. Publishing a document is different from writing a document. If you hold that the the data should only be accessed through the interface, then you would not publish the file format, now, would you?
I laughed when I read that line. The first OO adopters generally saw themselves as architects. The idea of "breaking things down into procedures" was part of the old "legacy" way of thinking. The OO architects build things up from objects. A person doing OOP isn't a computer programmer. When you think in OOP you are architecting systems, not programming computers.
The really funny thing is that OOP is systematically becoming more like the traditional programming paradigms that it was supposed to transcend.