OpenDocument Voted In By ISO 179
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? (Score:2)
Re:Sabatoge? (Score:4, Informative)
Beatting a Dead Joke... (Score:2)
Re:Sabatoge? (Score:2)
Re:Sabatoge? (Score:2)
Of course, it's hard to say whether the MS rep would be caused problems if the potential hadn't been pointed out, and MS hadn't been forced to prom
Hopefully not... (Score:5, Insightful)
ECMA are welcome to OpenXML, I don't think ISO should accept it.
Re:Hopefully not... (Score:4, Interesting)
"human point of view"... (Score:2)
Same thing? (Score:2, Interesting)
Re:Same thing? (Score:2)
mathML sucks. (Score:3, Informative)
Re:mathML sucks. (Score:3, Interesting)
the mathml equivalent?
Re:Hopefully not... (Score:4, Insightful)
Re:Hopefully not... (Score:2)
Feel the draft (Score:2)
Re:Hopefully not... (Score:3, Insightful)
Comparison (Score:3, Interesting)
Re:Comparison (Score:5, Insightful)
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.
I think software is less well understood (Score:2)
1) Many projects are hacked together without good requirements. There are even methodologies which minimize requirments, see RAD or Agile Development. In some cases the users often are unsure of the requirements and they are discovered by accident, if at all.
2) Most requirements have a strong temporal association. Meaning what is a requirements in May may not be a requirment in August du
Re:Comparison (Score:3, Interesting)
In engineering, building blocks are developped probably once per decade. How old concept of building houses of bricks? of wood? etc. You can't do much with physics, which describes the laws of the world we see around us.
In software engineering, earth gets reinve
Re:Comparison (Score:2)
Integration was wonderful until your computer was networked- then the "storm" of pressure from outside forces caused many unforseen failures.
There are others. If software is -only- used in a static manner then your point holds. But in the real world, only dead software is used that way. Living software is constantly reused in unforeseen ways due to changing circumstances, legalalities, competition, etc.
Re:Comparison (Score:4, Insightful)
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.
Re:Comparison (Score:3, Insightful)
Software...
(snorts)
well-understood...
(busts into laughter)
rules... well defined...
(roars with laughter)
I don't know which is funnier, you
Who are you kidding? (Score:2)
Why? Engineers understad the beams of steel at least as well as the software engineer understands the computer, if not moreso. The civil engineer understands the force of wind often better than the software engineer understands the force of data entry error. And most importantly, the civil engineer understands the use requirements better than the so
Re:Comparison (Score:2)
Re:Comparison (Score:2)
And here I always thought that that bridge collapsed in 1940.
Re:Comparison (Score:2)
In other words, you're right that the engineering standards in place at the time were not entirely adequate, but there was no adequate alternative either. One would not emerge for about thirty years, at which point engineering practice would be revised.
It seems to me that this pattern of progress is mostly okay. It should give us a big dose of humilit
Re:Comparison (Score:2)
By definition, chaotic systems are sensitive to initial conditions, so small changes in the intial states make big lon
Re:Comparison (Score:3, Funny)
Maybe mathematicians don't use it, but I use it daily, from the filing of my papers on my desk to the files in my $HOME, chaos is everywhere !
Re:Comparison (Score:2)
Re:Comparison (Score:2)
--jeffk++
Re:Comparison (Score:2)
This gives me more amunition. (Score:4, Insightful)
The parties involved I believe will be in the knowledge that this standard ie free for all to implement. Kudos to ODF.
Re:This gives me more amunition. (Score:2)
Re:This gives me more amunition. (Score:2, Insightful)
Re:This gives me more amunition. (Score:2)
Good. Then OOo/KOffice/etc can stop fighting to keep up everytime MS releasing a new Office and changes the format slightly. They can then focus on something important.
Re:This gives me more amunition. (Score:2)
I believe KOffice has a utility for just that. Of course, I imagine people that entrenched in MS Office docs aren't going to randomly decide to switch to Linux (not before they unentrench themselves at least) but at least that tool is out there.
Re:This gives me more amunition. (Score:2)
I think Microsoft can quite easily "kill" ODF just by their sheer market dominance. If their ODF import and export filters are broken enough such that ODF documents imported into Office are all rendered wrong and/or print garbled.... And then all they have to do is not fix it for years until ODF is dead. All the while, they
Re:This gives me more amunition. (Score:2)
governmental agency to add "ISO standard file format" as a checkbox on their
requirements list and suddenly MS is forced to either support ODF or go
home.
Re:This gives me more amunition. (Score:2)
Suppose that they do implement an adequate ODF import/export filter.
But it takes 10 minutes to import or export a simple 5 page document.
That would keep only the determined using it... everyone else will stick to Microsoft's preferred format because it loads and saves in seconds.
Re:This gives me more amunition. (Score:2)
If you compare how to add a printer and how to print in OS/2 1.2 and Windows 3.0, I would say that Microsoft does spend money pissing off customers.
Re:This gives me more amunition. (Score:2)
"ISO? But I think my Nero program can burn MS Word documents into ISOs..."
Re:This gives me more amunition. (Score:3, Insightful)
Whoa there, Mr. Snarky. (Score:2, Troll)
Re:Whoa there, Mr. Snarky. (Score:2)
(More seriously, though... how big of an advantage being an ISO standard is to OpenDocument in terms of adoption is likely to vary with whether OpenXML ends up being ratified as well).
Re:Whoa there, Mr. Snarky. (Score:2)
Gotta wonder why I was modded -1 Troll though, since I was only pointing out that the existence of OpenXML shouldn't dampen what is actually good news.
Good news (Score:3, Interesting)
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 (Score:2, Interesting)
Maybe you put high res graphics and are using tracked changes?
Tom
Re:Good news (Score:5, Informative)
Re:Good news (Score:2, Insightful)
Remember, there are tradeoffs to almost every design decision, compression included.
Re:Good news (Score:2)
Re:Good news (Score:2)
Word document horror stories. (Score:2)
It weighs in at (drumroll, please)
This is for two pages, mostly consisting of blank space. I am absolutely at a loss as to why it's so huge; but it's a standard template that we have to use, long predating me, and I'm not going to rebuil
Re:Word document horror stories. (Score:2)
I'm not defending word. I just made a blank document, e.g. CTRL+N CTRL+S test.doc [enter]. It's 23KB on disk. On the NTFS drive it's compressed to less than 4KB. So it's probably a whole bunch of reudndant crap. That said it's not super bad.
Like I said my text is less than 400KB for nearly 60 pages.
Of course there is a boat load of things Word does poorly [typesetting, formulas, etc] which it tries to make up with by having a hal
Re:Word document horror stories. (Score:2)
That said, you should be careful if the document is important as there can sometimes be some undesirable formatting changes. YMMV but I've found there is often no visible change to the document, just a smaller file, which for a template that is used a lot can result in a huge space saving over time.
Same applies for Excel spreadies.
ODF makes sense (Score:2)
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
Re:ODF makes sense (Score:2)
What is built around is is COM/DCOM and MS Office components. At which point the underlying representation becomes irrelevant (and can be changed frequently to churn the user base or disrupt competition or introduce new features).
The object interface published (or privately supplied) become the thing that other vendors are beholden to. Supplying speech i/o, integration, reporting, and whatever else. It has to be (relatively) sanctioned by
Re:ODF makes sense (Score:2)
A little funny that you should mention owning Microsoft stock: last year I got so fed up with Microsoft's file formats, that I actually sold the bit of Microsoft stock that I had.
Try writing a few c
Re:ODF makes sense (Score:2)
If you don't think that open document formats, an open internet, etc. are not important, you certainly have the rights to your own opinions.
Formulas? (Score:2, Interesting)
Mixed content model... (Score:4, Insightful)
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.
Re:Mixed content model... (Score:2)
The use of an external manifest to resolve links was criticised because it's harder to get at the data. With xlink, everything is right there in the tag - with the MS system, you have to take the ID, open up the manifest, find the tag with matching ID and then get the data off that. It's more complex for no good reason.
The mixed content model is a valid point. Look at t
Re:Hopefully not? (Score:5, Insightful)
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.
Re:Hopefully not? (Score:2)
With the exception of attributes (which, as I mentioned, are a wierdism of XML), XPath would be about the same if you used it with any other serialization language, and the only difference in XSLT is that it would look like the data serialization language rather than XML.
Which means no extremely noticable differences.
What features of XML are you talking about that aren't in JSON or YAML beside
Re:Hopefully not? (Score:2)
Well, off the top of my head, here are a few things that XML can do that JSON/etc. cannot do:
You cannot solve any of those problems in JSON or YAML in such a way that any other JSON or YAML app can understand without making changes to those
Re:Hopefully not? (Score:2)
Character set is something that is specified in the document. How would that change?
It seems you're still using "codebase" arguments, rather than "actual features of the format."
You cannot solve any of those problems in JSON or YAML in such a way that any other JSON or YAML app can understand without making changes to those apps. XML can do all of those things and more, and it's useful
Re:Hopefully not? (Score:2)
That's exactly the point - all XML readers support these basic things, it's not format specific.
One word. (Score:3, Insightful)
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.
Re:One word. (Score:2)
But when everything is strings, you get all the funny strange problems with decimal-, thousand-, time-, and dateseparators. So you gained some and lost a lot.
M.
Re:Hopefully not? (Score:3, Interesting)
That is perhaps the biggest mistake developers make when they design their XML schema (or DTD), and leads to ...
I hate XML. It's not easy for humans to read as a wire protocol.
If you keep the things that are supposed to be human readable as the text within node
Re:Hopefully not? (Score:2)
Re:Hopefully not? (Score:2)
No, that's not what the article says. OpenXML will not mix node and text siblings; that's nothing to do with whether or not you put data in as text nodes or node at
Re: (Score:2)
Re:Hopefully not? (Score:2)
I think XML has its uses. It is somewhat difficult to read for both humans and computers, but not that much. It's a good compromise since it should be easy to read with the right library, while still human readable for emergencies. I think it's good for machine readable files, like word processor documents and such.
Re:Hopefully not? (Score:3, Interesting)
JSON and YAML are more focused formats intended for lightweight transmissions and compatibility with existing computer languages, and tend to complement XML rather than supplant it.
XML is designed as a "catch-all" format that is capable of storing any form of data. That makes it extremely powerful, yet sometimes quite unweildly.
Each format has its tradeoffs, and as a result it is hard to say that one is "better" than the other. For example, XML's ve
Re:Hopefully not? (Score:2)
No. For example, I have problems reading this bit from an XHTML document:
*/
function comparisonFunction(i,j,k)
{ if(i<j)
if(j<k)
return k;
else
return j
else
if(i<k)
Re:Hopefully not? (Score:2)
Re:Hopefully not? (Score:2)
Having a structure which can be used to build unambiguously parsable data data formats is a Good Thing. Having some level of self-documentation
Re:So much for the list of experts (Score:5, Insightful)
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 (Score:2)
Well, I think a lot of them would appriciate it if they were (See Sarbannes-Oxley)
Re:So much for the list of experts (Score:2)
Exactly -- religious organizations are used to trying to piece together tattered 1000-year-old manuscripts that were written in a dead language and with
Re:So much for the list of experts (Score:2)
But if you look at the selling points of most corporate/enterprise email systems (e.g. Notes, Exchange), one of the big features is "document expiration." You can make it so that emails just magically disappear after some preset time...unless of course someone printed them out or saved them to a text file. Although I would expect that future systems might prevent this on certain documents (if they don'
Re:So much for the list of experts (Score:2)
Re:So much for the list of experts (Score:2)
Basically, you send them all of your paper records and archives, and they store them for whatever the legal period is, in some warehouse or bunker somewhere. Assuming you don't ever call them up and request the records, they'll destroy them at some preset date (2 years, etc.). Or whenever you stop payi
Re:So much for the list of experts (Score:5, Insightful)
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.
Re:So much for the list of experts (Score:2)
You'd think that religious organizations would want these documents to be lost forever.
Re:So much for the list of experts (Score:2)
The Apocrypha? Definitely not! Many of these texts are perfectly valid Christian documents that simply were never intended to be part of the Bible.
The Gnostics? Eh, it's history. Sort of. Some people would argue that the church is destroying "the truth" (*cough*Dan Brown*cough*) if the texts were extinguished, and that certainly wouldn't help people decide for themselves. That being said, the shear volume of Gnostic texts
Re:So much for the list of experts (Score:2)
Would it injure you to use that lump of grey matter between your ears before making such an inane comment?
Re:So much for the list of experts (Score:2)
Characterizing a scholarly society revolving around the study, analysis, archival and dissemination of historical documents as a group of "nutters", without any evidence other than the area of study those document
Re:So much for the list of experts (Score:3, Insightful)
> 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
Re:One small standard for a man (Score:3, Insightful)
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
Re:What technical weaknesses in OpenXML? (Score:4, Insightful)
Circular Arguments are not a technical weakness (Score:2)
Now the examples given at Groklaw show the real technical weakness of OpenXML/MSXML. It is basically a byzantine nightmare of complexity to(humanly) read
Not technical, but business reasons... (Score:5, Informative)
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? (Score:5, Informative)
Re:What technical weaknesses in OpenXML? (Score:2)
Re:What technical weaknesses in OpenXML? (Score:2)
The fact that
is completely useless as a way of exchanging information between vendors. Yes, the framework may resemble other popular standards, but the actual contents can be arbitrary blobs of opaque badness. That solves nothing.
patents (Score:2)
This needs to get discussed first.
Re:What technical weaknesses in OpenXML? (Score:3, Interesting)
I believe that some information that will help explain this is to be found here [groklaw.net]. It's best to read that article for yourself, but I'll provide a little abstraction of some of the details myself, although this isn't really my area of expertise:
The main point revolves around the fact that MS' OpenXML uses a non-mixed content model, while OpenDocument uses a mixed content model. This means that OpenDocument can have tags interspersed with regular text, or tags within text delimited by other tags, etc. Howe
Re:Showing my ignorance here... (Score:2)