OpenDocument Voted In By ISO

cduffy writes "OpenDocument has been voted in as ISO/IEC 26300, with no dissenting votes and a small number of abstentions. There are still several formalities to take place before final issuance. Now the question: Will OpenXML get the same treatment, despite its technical weaknesses? There's also coverage on Groklaw."

Sabatoge?

Wasn't this the one that Microsoft was going to sabatoge? What happenned to that?

Re:Sabatoge?

As far as I know ISO only has standard organisations as members, which represent a country (ANSI for the United States). As I remember Microsoft took place in a workgroup, which only makes minor edits (IANASG). See http://www.iso.org/iso/en/aboutiso/isomembers/Memb erCountryList.MemberCountryList [iso.org]

Hopefully not...

Although ODF is a bit nicer standard from a human point of view, and builds on existing standards, I hope OpenXML isn't accepted simply because having two standards doing the exact same thing is nonsense. They're much more similar than they are different at many levels.

ECMA are welcome to OpenXML, I don't think ISO should accept it.

Re:Hopefully not...

Nicer from a human point of view means less bugs down the line. I just spent a week trying to get an .wsdl to parse through Axis AND .NET's wsdl.exe. Any format that is less opaque, less verbose and more understandable gets my vote.

Re:Hopefully not...

Well, the day Microsoft accepts ODF as their standard is the day pigs are flying in a snowstorm through hell. From what I can tell, it seems anyone looking for a standard is looking at ODF, not the "Microsoft Office 2007"-standard. The MS shops will continue to run MS-only if it's binary or xml, standard or not. If they want to open it up and call it OpenXML so we can get proper documentation to migrate away from it, I really don't think that's going to hurt ODF. At any rate, if they really do the same one would think excellent ODF/OpenXML convertors could be made to make this a non issue. Same way I really don't care if an image has gone from BMP to PNG to TIFF and back again.

Comparison

If you look at the history of standards, such as done at NIST, usually people try to choose the best thing, but it is hard to forsee what is the best. A good example are the standards associated with how to quantify vibrations in static structures, such as bridges. Looked good in 1948, turned out bad (Tacoma bridge).

Re:Comparison

[What] looked good in 1948, turned out bad (Tacoma bridge).

There's a huge difference between construction engineering and software engineering. In construction engineering, poorly understood physics and unforeseen weather patterns can create unpredictable situations and stresses. In software engineering, the rules of the system are predefined and well understood. While a lot of research goes into ways of doing specific tasks "better", the tradeoffs to each design are usually well understood.

The result is that standardized computer algorithms and formats are rarely incorrect. However, they do become obsolete in relatively short periods of time due to increases in computing power and informational storage/transmission requirements.

Re:Comparison

In software engineering, the rules of the system are predefined and well understood.

Until you give it to the users, or ask it to interact with another program, then it's a different story. The actions of users/other programs are often poorly understood and unforseen, and I'd argue they are analogous to the weather in this situation - they introduce inputs that the programmer would dismiss as impossible or garbage, and promptly crash that 'perfect' program. I'd agree there is a huge difference between contruction and software engineering, but which profession is more rigourous?

The result is that standardized computer algorithms and formats are rarely incorrect.

Algorithms and formats are often incorrect when they actually come to be used because of a misunderstood or misstated problem. Look at the language used to present these pages - HTML, hardly an elegant format. I suppose you could call it correct for some very sloppy values of correct, but really, given the purpose it's being used for (presentation of complex styled text) it is woefully inadequate, and also overengineered in some ways. This problem is inherent in any complex system used by many people, things simply can't be 'correct' for all uses, and often they're not even close. I wonder if that's why the phrase 'Broken as designed' originated in computer programming?

Lastly, formats usually become obsolete because companies want you to buy their new program, not for technical reasons (see Photoshop, Illustrator, Word etc etc). You're trying to factor the human out of programming, and thus ignoring all that is good and bad about it.

Hopefully not?

I hate XML. It's not easy for humans to read as a wire protocol. It's not easier for computers to read than binaries. So I don't see the point, since that's what it's used for almost exclusively. Adding to that is the fact that attributes and nodes are two different things that are, in general treated the same (and the functionality can be achieved without attributes by making an "attribute" node and putting all the attributes under it).
We should be using something like JSON or YAML.

However, DOM and XSLT are both awesome ideas - especially for parsing documents.

Maybe this will lead them to adopt an XML-equivalent technology that is easier to read and parse.

Re:Hopefully not?

Well, I would agree with you about XSLT - but that's an XML technology, you realise? XSLT is actually one of the handy tools which you have access to. As an example, I was able to convert a large number of documents from HTML to OpenDocument using XSLT, and I would have had to write my own parsers etc. if the files on both sides weren't XML.

XML is handy because there's a lot of wheel reinvention that you just don't need to do. Also, it's not just a way of structuring data - comparison to JSON or YAML isn't really well-founded, they're not feature equivalent.

What technical weaknesses in OpenXML?

What specific technical weaknesses are in OpenXML? Sincerely I'm interested (and need to make some decisions for my company on this), but I don't want religious crap, give me the real technical differences.

Re:What technical weaknesses in OpenXML?

Well, for one, ODF is an ISO standard and is implemented in a bunch of different programs now, and OpenXML isn't. Lack of interoperability is a pretty crippling technical weakness, since we're talking about a document format.

Not technical, but business reasons...

OpenXML is patent ridden and in a way that is problematic at best, compared to OpenDocument. ODF is also patent ridden, but unlike MS' offering, the patents have free licensing for conformant implementations and conformant means to the official stated spec, with the possibility of extensions becoming part thereof- unlike MS' offering which requires you to meet MS' shifting definition of what is/isn't compliant (i.e. it's not explicitly stated...) and you don't get to add improvements unless MS embraces and extends them themselves (i.e. if you've got extensions and MS doesn't approve of them, you're NOT at all compliant and can be sued for patent infringement...).

Technically, they're the same. This is the reason why people can't understand why MS is insistent on NOT supporting ODF as a format and trying to push OpenXML- unless they've got some ulterior motive. Now, they've little valid excuse for it.

Re:What technical weaknesses in OpenXML?

The Groklaw article points out a few of them. The most damning is that Microsoft has chosen to ignore existing, reusable standards like XLink, SVG, Dublin Core, etc. for their own proprietary tags. These standards were expressly produced because they represent reusable patterns that many document formats need but which shouldn't be respecified by each of them. The upshot is that parsing OpenXML will be a massive pain in the butt because none of your existing scripts / tools / editors etc. that may have built-in knowledge of existing standards will not work with OpenXML.

That would be nice, but....

"There's no doubt that this broad vote of support will serve as a springboard for adoption and use of ODF around the world..."

mmm, we shall see..

This gives me more amunition.

This vote will certainly give folks like me more amunition to take on companies like Microsoft at home. With this development, I can push for the following line:

..."The software must be able to read and write the OpenDocument format approved by ISO/IEC"...

The parties involved I believe will be in the knowledge that this standard ie free for all to implement. Kudos to ODF.

So much for the list of experts

Experts from Boeing, bring them on.
Experts from the Society of Biblical Literature?? Wtf?? What the hell
have they got to do with a computer data formatting standard??

Or did they just require some people who had experience of a
large project at its Genesis.

Re:So much for the list of experts

Actually if you think in terms of who's really interested in processing, archiving, and dissemenating large volumes of text to people all over the world, it's not hard to imagine that religious organizations would be at the top of the list. They have huge archives, and probably desire both interoperability and stability (no "format of the week" syndrome).

It's honestly tough to find many organizations that really are thinking past the next quarter or fiscal year; in most industries people are buying software and hardware for the here-and-now. If that document isn't accessible in 15 years, who cares? Outside of their mandated recordkeeping obligations (Sarbannes-Oxley, etc.) a lot of large commercial organizations probably wouldn't care if their documents were written with magic disappearing ink that rendered them unreadable in a few years or a decade. (To be fair, the majority of commercial text is probably nothing that you'd want to read in a decade -- memos, meeting minutes, reams of emails; most of it probably makes little sense outside its original context anyway.)

I think this attitude is shortsighted, but it's pervasive. Nobody wants to think about long-term storage, nobody wants to think about accessibility 10 or 20 or 100 years from now, except libraries, governments, and religious institutions. (And perhaps some of the very largest and longest-lived corporations.) So it makes sense that if you're designing a data format that you want to be around for a while, you'd want to bring on board the people who have the most interest in making it successful.

Re:So much for the list of experts

Experts from Boeing, bring them on.
Experts from the Society of Biblical Literature?? What have they got to do with a computer data formatting standard??

Isn't it obvious? Literary organizations have massive numbers of documents that need to be digitized and archived in perpetuity. As a result, they have a vested interest in using standardized formats that will be guaranteed to meet their needs for years to come. The Society of Biblical Literature is no different in these respects, especially as more and more fragments of apocryiphal and gnostic texts continue to be found.

Whoa there, Mr. Snarky.

OpenDocument is a good format, both from a user standpoint and a technical one. How you feel about OpenXML is another matter entirely, but it's not the one that just got voted in as an ISO standard.

Good news

If Microsoft implements OpenDocument (or anything like it) in Office 2007 it will make a lot of people very happy.

A blank Word document takes up eleven kilobytes, and a one page document takes up about forty. If this becomes the de facto standard for documents rather than the Word document format, then document file sizes will shrink significantly, and a lot of bandwidth and disk space on office networks will be saved as a result.

Re:Good news

I just tried it. MS Word 2002. New document no text, 20 KB. 500 Words from Lorem Ipsum, 23 K. 300 pages of that same first page repeated. 1,128 KB. OpenOffice.org 2.0. New Document no text, 6 KB. Same 500 words from lorem ipsum, 10 KB. 300 Pages of repeated text, 22 KB. Wow, too easily compressed. Lets try 300 pages of non repeated text. 329 KB. You save quite a bit. I find that once you start adding images and other things like that, you end up saving even more space.

ODF makes sense

I joined the OpenDocument Format Alliance (http://www.odfalliance.org/) recently - partly to keep connected with what they are doing and partly to support a good cause.

I understand how entrenched Microsoft Office is in many organizations but hopefully common sense will prevail - want permanent free access to your data? Then use ODF.

Although I am a 'programming language junky' (I am happily coding away in Ruby and Common Lisp this morning on a new long term AI engagement :-) I always think of systems as data with software added as needed. Seriously, get the data (structures, schema, persistence, etc.) right and the rest is easier. Who would want to build systems around Office formats?

Formulas?

I just hope that OpenDocument gets its formula standards in order. I've read in a few places that there is very little documentation in the standard proper about how formulas (for spreadsheets) should be stored and used, which could in time cause some compatibility problems. That being said, I'm glad that it was approved by the ISO... maybe in a few years I'll not have to worry about converting from one office format to another ad absurdum.

Showing my ignorance here...

But I would wager that microsoft WILL impliment ODF, then they will tag on some extra data that they call DRM and then all of a sudden, you can still be locked out of your documents for not paying microsoft extortion.... eerrrrr... subscription fees!

Mixed content model...

When comparisons between formats remark upon mixed content models compared to non-mixed asking "which would you rather transform" expecting the answer of "mixed" you know a lot of people throwing opinions around on this issue have never actually worked transforming XML.

If you're wanting a human readable document format you have XHTML. Use it and enjoy. If you're producing an interchange format for word processing applications I'll take unambiguous and explicit over ambiguous and implicit even if that is at the expense of human readability.

The MS model uses a manifest to resolve link references, the ODF uses absolute references... this is criticised by Groklaw on the basis of human readability. Not maintainablity, application use, refactoring or normalisation of data.

There are valid problems that can be cited for both formats (I wish for instance MS had stuck with XLink), but this is quickly resolving into another round of MS bad, anything else good. It's emotive and is in most cases prejudged before technical merits are weighed.

I guess I just resent being asked whether I'd prefer to transform a mixed content model by somebody I know has never done so.

Question on best document format

I REALLY like the idea of the OpenDocument format and can't wait to see it get implemented in various Word Processors.

I am a university student. As I starting my 4th year next year the research is going to be more 'intense' and I'm going to have to write longer papers. Stuff that I would like to present in a job interview to show my academic credentials, etc. And also be able to read it in 5 years' time.

I don't want to use plain text, HTML, or Tex/Latex (I've tried and its way too complex) and no thanks for Scribus suggestions.

I've been writing everything in MS Word for the last 6+ years. I don't care about my earlier work too much. But I don't want to be totally locked in. I'd use OpenOffice but the Mac version is too slow.

What word processor on Mac or Windows will use the OpenDoc format? To get nicely formatted (font, layout, etc) documents am I pretty much stuck to Word ... or is there another suggestion? I've used Pages a bit but my main concern is that I want a program that will easily read the files 10+ years down the road.

Hey, wait a moment...

Weren't we agreeing that we should start using lyx (or latex) so we can stop the formatting hell in WYSIWYG text processors?

Why not extend XHTML to support missing features?

Seriously, why not extend XHTML to support missing features?

Why do we need another OpenDocument, OpenXML syntax?

Like Groklaw pointed why do we need another XML syntax? when people know XHTML/CSS already?

MS Office can already support HTML for Word and Excel, very nicely.
It would be much easier to make Microsoft accept a new version of XHTML,
then to adopt something awkward like OpenDocument.

The only thing missing are better CSS export for custom types, individual page settings, printer setup, page margin, small caps support, font kerning, MathML and embedded SVG support.

I guess this is too simple:

<html><body>
<page width="8.5in" height="11in"
margin="1in,1in,1in,1in">blablabla
<footer pos=".5in"><center>Page 1</center></page>

<page width="11in" height="8.5in"
margin="1in,1in,1in,1in"><header pos=".5in"><center>Confidential</center>
blablabl a
<footer pos=".5in"><center>Page 2</center></page>
</page>
</body>
</html>

Re:One small standard for a man

"The movement toward OpenDocument in the free world, warms the open cockles of my heart. (Emphasis mine)

I sure hope the chambers of your heart aren't open, you might want to visit the doctor if so.

But if the cockles you're referring to are the bivalve mollusc kind, they are always open -- cockles don't shut. However, they are hermaphroditic and they can jump. Which still presents a problem for your cardiac health.

Seriously, though, formal recognition of this standard removes one of the obstacles to widespread implementation of non-MS office software. The bigger hurdle, of course, is retraining & support expenses (for businesses) and factory (or pre-purchase, anyway) installation of the software (for home users).

This doesn't change the fact that MS formats are the de facto standards in use, but it may help unify the communities that use non-MS formats, leading to a larger install base.

OOo != ODF

You are comparing the 'effeciency' of fruits to the effeciency of fruit squeezers? ODF is the file format. MSOffice is an application. The linked article compares the ODF reading/writing capabilities in one implementation (OpenOffice) to that of Microsoft using its binary memory/OLE dump. You're not looking all to bright by doing that.

The linked article, btw, starts to spreads unfounded idiot opinion at the paragraph that explains the file format specifications are "a non-issue" to the author and goes further with lying: "But this is argument is fundamentally flawed because the existing Microsoft Office binary formats are effectively the de facto standard and are effectively open to anyone."

If the meaning of the word "open" is twisted to "can be implemented with lots of guesswork" and "compatiblity can be broken by a whim of Microsoft", then, yes, the author is right. But as it reads, the author here just slightly invented a "fact" to bring his point around.

Re:"technical weaknesses" ?

I don't trust your quoted source. The objectivity of your cited article can be seen in the following definition of openness:

"The Microsoft Office formats are open in the sense that every Microsoft Office competitor from StarOffice to OpenOffice.org to Word Perfect to ThinkFree Office has reverse engineered the Microsoft Office format and uses it freely yet they've never been sued by Microsoft for doing so."

Re:"technical weaknesses" ?

DUH of course, it's binary vs XML file format!