Slashdot Mirror
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."
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.
"Elmo knows where you live!" - The Simpsons
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.
"Elmo knows where you live!" - The Simpsons
[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.
Javascript + Nintendo DSi = DSiCade
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.
Interoperability.
I agree there's much overhead having to translate between text and binary data, but the point is that XML isn't used for exclusively processing. It's for INFORMATION INTERCHANGE.
OpenDocument is an xml format, but it's an OPEN format, completely documented and with no loose ends. Furthermore, it's very similar to HTML, so the algorithms to process it are similar, too.
On the other hand, Microsoft's "Open"XML... eew.
The parties involved I believe will be in the knowledge that this standard ie free for all to implement. Kudos to ODF.
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.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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.
Javascript + Nintendo DSi = DSiCade
"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.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
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.
> Experts from the Society of Biblical Literature?? Wtf?? What the hell
> have they got to do with a computer data formatting standard??
Oh I dunno. ODF had as design goals support for longterm document storage and seamless internationalization support. I suspect the Society of Biblical Literature has an interest in both. Unless you are so ignorant that you believe Moses and Jesus spoke the English of King James that is. You probably wouldn't believe just how many languages and scripts the original texts are written in. If ODF can deal with all of those it shouldn't have a problem with any of the modern encodings.
And if you know of anyone with older documents, and likely to still be using them a thousand years hence, speak up.
Democrat delenda est
(snorts)
well-understood...
(busts into laughter)
rules... well defined...
(roars with laughter)
I don't know which is funnier, your post
(laughs louder)
or the fact that it is modded up for insightful instead of for funny.
(falls off chair, gasps, struggles to stop laughing so hard)
C'mon, 'fess up: you were being snarky. And if this was a successful trolling, you are da man...
(busts into giggles again)
Wow...
(wipes tears from eyes)
Software engineering being superior to civil engineering --
(starts laughing again).
Poorly understood physics --
(more laughter).
Man, I wanna party with you -- that's some fsckin' brilliant trollage.
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.
Okay, so far so good. Now corrupt the first 300 bytes of the file. See which one allows you to get the data back. If you are really committed, you might be able to get some back from the Word document, by going in and copying out small sections of contiguous text. From OO, you probably can't. From a plain text file, it is easiest.
Remember, there are tradeoffs to almost every design decision, compression included.
I am a sig. I wish I were a more creative sig, but I am not. I guess everyone has something to strive for.