Danish Study Recommends Open Standards for EU

PDAJames writes "The Danish government has wrapped up a two-year study of open source's potential for the public sector, and has some pretty interesting things to say. For one, it says that tie-ins to proprietary software effectively eliminate competition for government procurement and are inherently bad. For another, it recommends a public sector-led effort to adopt an XML-based standard document format, either that of OpenOffice or a new one developed by the EU. Will they push ahead with these plans or is it just more talk?"

Comments

Inherently bad?

[BWJones]

it says that tie-ins to proprietary software effectively eliminate competition for government procurement and are inherently bad.

Well, I might say that if one were considering government procurement only, they might be inherently bad. But there absolutely *is* good software out there that is proprietary that is good, and better than anything available open source. This is not to say I am not in favor of open source. Quite the contrary, I believe in an open source foundation, but companies should be allowed to bid on contracts for their proprietary products as long as those products are either based on open source, or support open source formats and alternatives.

Re:Inherently bad?

[Anonymous Coward]

The two statements are not necessarly exclusive. Tie-ins to proprietary software are indeed inherently bad, because they limit the user's ability to change to different software later. If the difference in quality between the proprietary software and any competing software is great enough, it can be enough of an advantage to overcome the disadvantage of being tied to proprietary software.

However, if I were a large organization requesting bids for software that included proprietary data formats, I would require that the ability to export data into an open format be included.

Pure and beautiful XML document format won't exist

[Leeji]

I've been thinking about the XML document format problem, and I don't think there will ever be a "pure and beautiful implementation" that will ever be perfect.

As the capabilities of the document format grow, people gain the ability to embed images, arbitrary objects, graphs, etc. Much of this can be written in a self-describing style (ie: plain text XML nodes,) but there comes a point where the developers have to simply hack XML and embed some nasty CDATA kludge.

Just looking at the embedded image problem alone -- static SVG is a great, pure-XML image format. Unfortunately, it will never have the power to describe the full set of images that you could create in a binary format.

Re:Speaking of

[Elektroschock]

This probably refers to the German (Schleswig - Holstein) based initiative 1dok e.V. They want to establish a standard file format for word processing based on XML.

Bundles are the answer!! NeXT had this years ago..

[avarame]

Better yet than XML... bundles!!!

Go research .rtfd files on NeXT and Mac OS X. They're basically super-RTF files. They are actually a folder ending with .rtfd that the operating system presents to the user as a single file (for mere aesthetic and encapsulation reasons). They contain an RTF file and all the non-RTF resources (images, sounds, etc) that are embedded in the document as separate files in their own formats. I believe images are saved as TIFF by default.

So why not combine open XML document formats and rtfd-style bundles! A complex document is really a folder full of files, but it appears to the user as a single file. This makes it easy to move around, esp from computer to computer, and presents a nice sensible metaphor to the user. It's also difficult to screw things up by messing with the components (but it is possible to get into the bundle if you need to). Inside these complex documents is an XML file that describes the components of the document. Then there are files that contain the components, in whatever (open) format you wish. RTF or OpenOffice or whatever for text, Ogg sounds, PNG or SVG images, CSV or more complex spreadsheet/table formats, all the fonts the document needs, etc.

One of the replies to the parent addressed the issue of pixel-exact rendering. That's easy - just use the same rendering engine everywhere! All Gecko browsers render exactly the same everywhere (assuming the same fonts are available). So just use a single homogenous rendering engine everywhere. (And include fonts in the document bundle).

I sure hope some brilliant application-software engineer reads this! :)

(Final note: Another, more risky option would be to provide an API for rendering modules written in some suitable language, which would then be included in the bundle. You want to render, say, Maya IFF images? Include the IFF renderer in the bundle. Of course great security precautions would need to be taken, and optimally the rendering modules would have access to nothing outside the document-world, and preferably only a buffer to draw into and layout above them would be managed by the program. This has been tried before, I think. But maybe its time has come?)

Re:Speaking of

[spektr]

Explain? "Warped" Vs. "True" XML? I didn't know either existed.

<!xml variation="1.000001" encoding="crazy">
<!redfine pattern="<" substitute="[">
[!redfine pattern=">" substitute="]">
[!redfine pattern="/" substitute="\"]
[worddoc]
[paragraph style="malicious"]
Executive summary: this is XML!
Whoops world, here I come! Take this Xerces! Watch out W3C!
[\paragraph]
[alternativeBinary thisistherealdocumentignoretherest="yes"]
magic:666
4($/HKDh3627KJHK/%$"%&&&%Ijhdifzsdfusdfuhd f
KDh3627KJHK/%$"%&&&%Ijhdifzsdfu"%"%$&737%& % ...
843578kjfh/&%"/&"%&%$/jghfdjd7&%&"%/"JHGD3
[\alternativeBinary]
[\worddoc]

This is just imagination. The reality is stranger than we imagine, in fact stranger than we can imagine.