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."
Wasn't this the one that Microsoft was going to sabatoge? What happenned to that?
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
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
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).
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
i am glad to see someone else whom sees the same light as me.. it makes me have hope in the world
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
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.
"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..
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.
XHTML is an XML technology, and humans can read it easily. MathML is a great language to learn, if you're interested in mathematics. There's more to XML than just plain "XML", that's why it's called the Extensible Markup Language.
Slow Down, Cowboy! It's been 60 minutes since you last successfully posted a comment.
The parties involved I believe will be in the knowledge that this standard ie free for all to implement. Kudos to ODF.
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.
XML is easier to program with and debug. When things go wrong, and they always do eventually, it's really nice to be able to just open up the failing object in a text editor rather than having to piece it apart in a hex editor or relying on a tool specialized for that format that could introduce its own problems.
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 nodes, and move the rest (formatting instructions etc) into attributes, your XML will be much more readable after some simple processing to remove the nodes. Using attributes for all those small name-value pairs that XML documents are full of also reduces the size and makes parsing more efficient.
You're not getting the point, really. XSLT is an XML tech because XML is a wire protocol - a way to serialize data.
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 besides attributes? Not requiring well-formedness? Fine. When I mean "JSON" or "YAML" I really mean "well-formed JSON or YAML." That should make it at least as easy to write parsers for.
DTDs? Work as well with non-xml.
I think by "feature" you actually mean "codebase." That's about all XML has over those other things. And even then you'd get to keep most of it, because a lot of that code is about structure, not formatting. Of course, I'm willing to be enlightened. What can you do with XML that you can't with another wire protocol at least as well?
Mod me down and I will become more powerful than you can possibly imagine!
Speak for yourself. I find this markup language fits my thought processes very well, and I enjoy working with XML and its dialects very much.
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.
What I do hate is developers thinking that XML is straight human readable. I hate people who uses straight XML config files (that I, being the administrator, have to edit by hand). On that part I'm 100% with you.
Anyway, ODF is XML. It's a bunch of XML files in a zip, so your criticism would apply to both ODF and MSXML.
GPG 0x1B479C78
I hate XML. We should be using something like JSON or YAML.
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 verbosity allows for parsing errors to be much more easily identified and repaired while simultaneously preventing accidental errors from going unnoticed. In YAML and JSON it is much easier to place unintended characters or data structures without the parser noticing. Neither one (to my knowledge) has the ability to check the structure of the transmission like XML DTDs and Schemas do.
However, DOM and XSLT are both awesome ideas - especially for parsing documents.
You've just given two reasons for the existence of XML. Both concepts are extensions of the XML concept, and are not necessarly applicable to other data-exchange formats. (At least not without massive changes.)
XML was designed with the DOM in mind so that any type of flat or heirarchical data could easily be loaded and stored programatically. This cuts down on the number of programs that attempt to construct an interchange document manaually. This rigid structure thus makes way for the programatic transformation of such documents, ala XSLT.
Javascript + Nintendo DSi = DSiCade
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."
Specifically based on this sentence: In software engineering, the rules of the system are predefined and well understood.
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 due to changes in the economy, the technology being used the regulatory environments (state, national, local or international regulations, treaties or standards) or if a company is purchased or merges with another company. So if a software project lasts 18 months, I will bet the requiremnts will have shifted in that time span.
3) Software cannot be touched, tasted, felt, smelt or seen. Just the results, such as a report, a graphic or a GUI. This makes it *much* harder to understand, esp. by the majority of the population who do not have either the training or the aptitude for this type of abstract reasoning. And we rely in a large part on these folks to help with requirements!
Your statement in the last sentence sort of overlaps point 2 of this comment, BTW.
Just my $.02
putting the 'B' in LGBTQ+
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.
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
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 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?
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 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.
It's not just nicer from a "human point of view"; it's simply more appropriate, technically, for the data it contains. Microsoft's half-hearted attempt at an XML format is like storing cars on a keyring with more keyrings attached: you can put all the parts on there, if you try hard enough, but it just makes no sense, for man OR machine.
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 apps. XML can do all of those things and more, and it's useful: e.g., embedding SVG into an XHTML document.
"Elmo knows where you live!" - The Simpsons
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!
Cliff Claven
K.E.G. Party Chairman
Founding Leader of: Koncerned for Egalitarin Governance
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.
;)
Well, I think a lot of them would appriciate it if they were (See Sarbannes-Oxley)
Live today, because you never know what tomorrow brings
XHTML is an XML technology, and humans can read it easily.
/* Compares I,J, and K and returns the greatest.
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)
return i
else return k
}
XML doesn't allow any of its nodes to NOT contain valid XML, so you end up using the stupid < > instead of . Either that or you have to use a CDATA tag, which really has no reason being there.
Mod me down and I will become more powerful than you can possibly imagine!
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 attributes.
"Elmo knows where you live!" - The Simpsons
So did ODF folks finally decide how to store formulas? Currently every single spreadsheet that supports ODF (not that there are many) stores those as they wish with no defined standard.
If you'd had enough opportunities to work with binary formats built for custom, one-off, non-source available parsers and XML-based formats and tools for manipulating them, I think you'd have changed that opinion by now. XML makes interoperability work much, much easier -- and is vastly more readable than the bit-packing one-off formats people come up with otherwise.
Having a structure which can be used to build unambiguously parsable data data formats is a Good Thing. Having some level of self-documentation properties on top of that is icing on the cake.
Actually, companies have a vested interest in aging (IE: Destroying or rendering illegible) documents. There's an entire industry, dubbed "document retention" that is actually focused on destroying anything that might be used as evidence in a legal proceeding as soon as it is no longer needed or as soon as legally allowable, whichever comes first.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
You sir, are being an ass. Did it ever occur to you that historical archives of all types are useful to more than just "religious nutters"? Or do you believe that the Odyssey should be discarded as a "work of religious nutters"?
Would it injure you to use that lump of grey matter between your ears before making such an inane comment?
Javascript + Nintendo DSi = DSiCade
> 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
Not everyone who's religious (or who studies religion) is a raving lunatic intent on making the rest of the world do things their way Because God Said So; it's just that set which makes the press, generates the noise, and results in bad laws and worse politicians being foisted off on everyone else.
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 documents correspond to... well, it's certainly inappropriate. Religion is an entirely legitimate field of study, even should you consider it bogus in every other way.
MathML is the worst way to store formulas ever. Anything that takes 5k of text to specify int(from 0 to infinity, exp(-lambda*x**2)dx) correctly is simply stupid. It means hand coding mathML just isn't a viable option for more than a couple very simple equations. We should agree on something similar to a C, Fortran, Matlab, or other programming language notation as the standard way to store equations in the file. The added benefit of potentially being able actually execute at least some of the functions is just icing on the cake.
On a related, but somewhat less relevant note is that I can't find any inexpensive programs that allow the generation of mathML easily. There are a few out there that generate mathML at all, but they seem to concentrate on the typesetting aspect of mathML* and on having an obtuse interface. Why isn't there a easy-to-find, cheap or free (beer or speech), mathML editor that is as easy to use as the equation interface in LyX? (and yes i've tried export-html options in LyX, and attempted to manually convert with commandline utilities but my latex2html functions all seem to be completely braindead.)
*iirc, there is a way to use mathML to store calculable functions, but I have yet to see this implemented, and it takes even MORE text to store the equations.
I think the lack of available editors, and tex converters, especially considering the potential academic utility of mathML is pretty good evidence that it is a poor standard: it hasn't generated enough interest for someone to scratch the itch and write a decent converter/generator/editor.
Can you be Even More Awesome?!
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.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
It's literature isn't it? After all, it's one of the most popular books of all time. And by that, I do mean all time. I'm fiercly non-religious, but lets be honest, the Christian Bible is a pretty widely read book.
Here is the draft of ECMA standard, enjoy its 2000+ pages of detailed info.
My other Beowulf cluster is... er...
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.
Namespaces are their own spec that was added onto XML afterwards. There's nothing keeping that from working anywhere else.
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: e.g., embedding SVG into an XHTML document.
The same can be said for any XML readers that don't support those formats. So?
Mod me down and I will become more powerful than you can possibly imagine!
it isn't that i majorly dislike xml.. i just dislike people who all of asudden think it is the only way of doing something
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
I didn't say you couldn't understand it. Just because you don't know what something means doesn't mean it's unreadable. Once it shows up in your web browser it's perfectly readable.
Slow Down, Cowboy! It's been 60 minutes since you last successfully posted a comment.
Just simple forced harmonic oscilation. Exactly like a sream of air [or a bow] vibrating a violin string.
One of my professers [at Brooklyn Poly] analyized the failure for his doctoral dissertation. [that would have been about 1940 or so]
He found that the Bronx - Whitestone bridge had the same failure modes, and was responsible for designing some remedial alterations to the structure.
Caution: Do not stare into laser with remaining eye.
Speaking of CDATA, how do you represent the string "]]>" inside a CDATA block?
http://outcampaign.org/
I actually almost mentioned that in my original post, but decided it wasn't directly relelvant to my point.
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't already -- I can imagine a "no print / no save" flag that was really enforced would be a big feature). Ignoring how hard that would be to effectively implement, of course.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
I also get the impression that binary formats are harder to compress than text formats (e.g. XML). Case in point: Microsoft DOC format vs. OpenDocument Text (ODT) format.
Finally, someone that uses objective analysis rather than religious doctrine regarding this issue.
-- "I never gave these stories much credence." - HAL 9000
There's an entire industry, dubbed "document retention" [kahnconsultinginc.com] that is actually focused on destroying anything that might be used as evidence in a legal proceeding as soon as it is no longer needed
I doubt that you are correct, since document retention means retaining (i.e. saving) documents. Maybe document expiration was the term you were looking for?
If that was true, software would be more reliable and robust than the Forth Bridge. Yet it is not, for any non-trivial control program (or operating system).
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 software engineer.
LedgerSMB: Open source Accounting/ERP
A simpler explanation: Before the meeting started, they cleared the room of all chairs.
;-)
The article says that ODF *just now* got approved as ISO standard and asks "Now the question: Will OpenXML get the same treatment, despite its technical weaknesses?". Your answer is basically that OpenXML should not be an ISO standard because its not already an ISO standard, while ODF is a standard. That says nothing about the inherent weakness of OpenXML
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 and therefore hard to parse. It also is encumbered by patent issues.
I once took a try at using the MS Office 2003 XML capabilities (such as they are) via VBA, but enventially gave up and took a different route, partially because the "XML" output by Office was a LSD trip to write a handler for. Instead I just inserted plain text via the Office Document model. So, yes, MS Office XML sucks, but for valid reasons other than not already being an ISO standard.
You think that's bad? I have a template that all of our meeting minutes gets typed into; this is a text-only (no embedded graphics) Word document. It has a bunch of tables and some formatting in it, but no tracked changes or anything. It's a very simple template.
... 275 KB.
.... that's a lot of wasted disk space thanks to an inexplicably bloated template document.
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 rebuild it. Every week we generate two or three of these, which depending on how much actual content gets put into one, ends up being around 300 KB or so. Multiply by 50 weeks, multiply by six or seven years
I'm sure other people can come up with even more egregious examples, but that's mine. I've definitely seen Word docs that have ballooned to a MB or more from a few hundred KB just from turning track changes on and changing a line or two (what the heck does it store in there? Is a diff not good enough or something?). But probably nobody outside MS will be able to tell what the problem is, since the format is a black box.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
That's exactly the point - all XML readers support these basic things, it's not format specific.
"Elmo knows where you live!" - The Simpsons
Have you ever heard of a euphamism before?
I've upped my standards, so up yours.
Patents e.g. http://gauss.ffii.org/PatentView/EP1376387
This needs to get discussed first.
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.
You'd think that religious organizations would want these documents to be lost forever.
You'd think that religious organizations would want these documents to be lost forever.
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 - all which contradict each other (I swear these guys were the original fan fiction writers or something) - makes it difficult to take them seriously for anyone who actually studies them.
Javascript + Nintendo DSi = DSiCade
It's one of those funny little twists of the language: "Document Retention" companies are very much in the business of destroying documents. They also retain and store them until they're ready to be destroyed.
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 paying for them to store them, whichever comes first I assume.
This is a big industry: the biggest player that I'm familiar with is Iron Mountain, but I'm sure there are others. Many of these companies also do secure document destruction, and will empty your "burn bags" around the office at the same time they come to pick up new boxes of files.
The advantage to a business is that you don't have tons of files sitting around that could become a liability later. When you get subpoenaed, you by law have to turn over all documents that you have concerning the subject of the subpoena. But if those documents were legally destroyed, after their required retention period was over, there's nothing to subpoena -- thus, there is a big industry in storing things for EXACTLY as long as is required, and then getting rid of them in a hurry.
Simply storing crap is easy; anyone with an empty warehouse could take your file boxes and stick them in a corner someplace. What companies pay for is the ability to retrieve information if it is needed, and the knowledge that after it doesn't need to be around any more, it'll be destroyed in such a way (and in a timely fashion) so that it won't come back and bite them in the ass. That's what they pay big bucks for.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
No, the biggest hurdle is making superior office software! From my limited experience, AbiWord is a decent document writing tool, and I have only a few gripes with OpenOffice.org Writer (namely rotating and flipping graphs), so beating MS Word is not a problem IMO. Excel, on the other hand, is the best spreadsheet software that I have ever used. It seems to contain more convenient functions, it has a nice sliding-bar feature to adjust values of a cell, and it handles large datasets ALOT faster than OpenOffice.org Spreadsheet! Once I had to make a graph of ~3000 datapoints (X & Y), and it took forever to highlight the entire row, and after I plotted the graph, the entire package slowed to a crawl. I then used Excel to plot the same points, and it highlighted and plotted the graph very quickly. Yes, OpenOffice has a shitty codebase that was developed by an obscure German company; however, this means we, the open source crowd, have even more work to do. Don't rest yet boys, 'cuz the party ain't over.
---- "XML is like violence. If it doesn't fix the problem, you aren't using enough."
On the contrary, KOffice will run on Windows very soon. Kdelibs are being ported to Qt4 as we speak, and almost runs under Windows already. The same is happening with KOffice, and I think we will see a proof of concept of KOffice running on Windows before summer this year.
If it takes you along time to highlight your data set, why don't you use named data ranges?
Re: work to be done -- of course. But the vast majority of most people I know who use Excel regularly only use it for keeping lists (or small databases) and sometimes minor functions.
Ideally, if you need to develop graphs and charts from your data, you should be using Openoffice Chart -- though it also needs some work (see the early March slashdot review/tutorial of Chart 2.0). This is a large point of interoperability, after all -- not only switch between different brands of the same application type, but also to use different applications with the same data.
At the office, I often use Crystal Reports to generate the reports I need from my Excel spreadsheets -- much quicker than generating reports in Excel using VLOOKUP or PRODUCT or the other tools out there. And heaven forbid I need to write yet another VB script to get the functionality I want, especially when I'll want that functionality across different files. The point is that it's important to select the proper tools for the job at hand -- and IMO, a spreadsheet is not a chart/graph generator, nor should it be.
I digress a bit, but there is a reason that MSOffice is so bloated -- they've tried to make each piece do more than it should. For those who never use charts in Excel, why should they have to install that functionality?
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
No they don't. If I wrote a small, simple XML reader, then it wouldn't. A lot of the ones for small scripting languages don't. The initial *point* of XML was to make something that was easy to write a parser for and easy to read.
If your point is that it works with all current XML readers that you use then the obvious answer to that for another language is make it work with all current wire protocol readers. XML hasn't been around that long; codebase arguments are rather weak. We can change the codebase if it'll give us great gains in other areas, and since most of the codebase has to do with *structure* rather than with *parsing*, pretty much anything in an XML parser can be ported to work with another format. So rather than arguing things on the basis of what a particular reader that you know can do, think about what you get from using things that are unique to xml - how it opens and closes sections, the existence of attributes, and the way you write singletons. That's all that XML has all to itself.
Everything else are things that are in XML not because its XML, but because they're good things to have as part of a plaintext wire protocol.
They have nothing to do with the fact that they're XML.
If you picked something that was smaller, easier to parse, and easier to read than XML you could easily apply the same standards.
Mod me down and I will become more powerful than you can possibly imagine!
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.
I REALLY like the idea of the OpenDocument format and can't wait to see it get implemented in various Word Processors.
... 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.
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
HTML was adequate back in the days of dialup when people actually used HR tags rather than styling borders on the bottoms of DIV tags and so forth, but really the HTML that people use nowadays in "real" web site design is actually very elegant. It has become less of just a markup language and more of a layout language, with the block layout model used by CSS. While this is true, the old HTML code will still work and you can learn all the new stuff having a cursory knowledge of old-school HTML.
In this way, HTML is just fine, because it's been easy to expand it and adapt it to changing requirements and capabilities of users and servers. I think that ODF, being in the spirit of that same standard (XML), as it's been commonly used with respect to documents, is definitely the winner here. As new capabilities or requirements come about, the standard as described now is flexible enough that it can be extended easily without breaking a lot of applications in the process. What has resulted is a number of different "standards" that are all accurate, but one is definitely identifiable as being more recently defined than the last as opposed to equally-accurate and equally-relevant standards being developed and specified in parallel.
I guess I learn something new every day. Thanks!
Apparently you are unfamiliar with the nature of corporate NewSpeak. Frequently, when used by corporations, but especially by lawyers, things mean the opposite of what they would appear to mean in plain English. Hence my enclosing the phrase in quotes.
Kind of like the fact that "Compliance" usually means ways to do the bare minimum to meet the appearance of having complied, not actually complying.
I was very rudely awakened to this fact when attending a conference where I was looking for ways to help companies comply with both the letter and the spirit of the Sarbanes-Oxley act, and found that the vast majority of attendees were there to figure out how they could end run it, but not get caught.
Weren't we agreeing that we should start using lyx (or latex) so we can stop the formatting hell in WYSIWYG text processors?
DUH of course, it's binary vs XML file format!
sw5YRhw4ln3pr7$Ock1/4ma0u8Lw2Tm5l6/7DOiC5e6t4NSb6
Seriously, why not extend XHTML to support missing features?
l a
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>
blablab
<footer pos=".5in"><center>Page 2</center></page>
</page>
</body>
</html>
Gnostic texts - all which contradict each other (I swear these guys were the original fan fiction writers or something) - makes it difficult to take them seriously for anyone who actually studies them.
And, of course, the content of the Bible comes from exactly the same types of souces, only it has the royal penguin piss. It'd be dangerous for the church if religious people ever figured this out.
Apparently you are unfamiliar with the nature of corporate NewSpeak.
There may be several explanations for this. Although I consider myself fluent in the English language, it isn't my native one (which is Swedish). This means that certain terms that, like the ones you mentioned, mean the opposite of what they seem to mean, might be unfamiliar to me. The second reason is that I (currently) do not work in the coporate world, but in academia. And as a Swedish government institution we have a legal obligation to keep much of our documents archived for ever, so I do not come into contact with such document retention policies, rather the opposite.
But thanks for the heads up.