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."

Comments

Sabatoge?

[penguinoid]

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

Re:Sabatoge?

[XiQ]

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

Re:Sabatoge?

[Anonymous Coward]

Real religious types follow their fairy tales TO THE LETTER.

Re:Sabatoge?

[CarpetShark]

Maybe they figured that questioning an honest man's integrity, costing him his job, and risking his mental wellbeing when he's not used to media pressure was enough for a little while. Don't worry, Microsoft will be back to playing hardball on this soon though.

Re:Sabatoge?

[iabervon]

They then said they weren't going to sabotage it, and that they were only on that committee because they were going to push for acceptance of their format. A number of ODF-related organizations had representatives on the committee, and it's common for interested organizations to be members, because they can actually explain the reasoning behind the specification.

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 promise good behavior.

For that matter, the ODF reps will presumably sabotage MS's submission, just like they accused MS of trying to do. But, of course, they're supposed to stop the group from endorsing standards that are worse than other standards.

Re:Sabatoge?

[thealsir]

The real world and the slashdot world differ, sometimes radically.

Hopefully not...

[albalbo]

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...

[DrXym]

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...

[Kjella]

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.

Re:Hopefully not...

[g2devi]

Maybe, but don't forget that Microsoft is in an Anti-Trust investigation in Europe. Suppose the EU decided that the only way MS Word would be available is if MS Word support the ODF file format and saved files *by default* in ODF format. That would pretty much level the Word Processing playing field and allow Microsoft to "innovate" freely since the only reason for chosing Microsoft the would be that you like their software.

Re:Hopefully not...

[moochfish]

I thought the point of standardizing something is to keep there from being 100 "official" ways to do it. What's the point of having fifteen approved "standard" document formats? I'd say this getting approved is the nail in the coffin for Microsoft's precious standard. There can only one standard and ODF is now it.

Comparison

[2.7182]

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

[AKAImBatman]

[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

[ThePhilips]

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.

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 reinvented completely more or less every decade. Every new generation of computers allows newer improved algorithm and new application fields to be sucked in. And everytime people find that the algorithms can be improved even more. 200 hundred years ago, simple automation of money counting was unimaginable. Try to consider what happen in the two centuries. And how the process evolved, if now amount of money has *no* physical equivalent: it's just number our bank stores along with rest of account information. Numbers can evolve thou they exist only in our imagination. You hardly can expect brick or lump of iron to evolve in any similar way.

Standards if they want to remain useful has to evolve. IMHO standard has to include way to add improvements and way to move the improvements under standard umbrella. E.g. HTML is tag based. There is a definition of tag along with its properties. Improvement to HTML can be done in two ways: new property of an exsiting tag or a completely new tag. And with next revision, schemas can be updated to include the improvement. It worked that ways with HTML evolution from ver 1.0 to 4.0 to XHTML 1.0. Make HTML an international standard requiring strict compliance and 6 month aprove period for every new feature - and you would find that the HTML would have never evolved that far the way it did under the rule of W3C.

ODF inherited from XML easy way to add improvements. If ISO workgroup isn't made up of complete [CENSORED] - and luckily to us it isn't - standartization would not stand in a way for improvements.

What is remaining for ODF to be healthy standard - is competing implementations. KOffice is limited to KDE which doesn't run under Windows. Working with OOo every day I wish it was never ported to Windows in first place. I hope the Corel would deliver on promise and add to competion. Having at moment under Windows only OOo as an option - hardly helps ODF adoption.

Re:Comparison

[CrimsonAvenger]

Looked good in 1948, turned out bad (Tacoma bridge).

And here I always thought that that bridge collapsed in 1940.

Re:Comparison

[Maxo-Texas]

I think microsoft office integration is a perfect counter-example to your point.

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

[starfishsystems]

I read recently that the Tacoma bridge failure was due to a characteristic of suspended structures that could only have been modelled using chaos theory.

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 humility when we're contemplating building nuclear reactors, which is why they talk about the Tacoma bridge in engineering classes. On the other hand, an imperfect document standard, say, is quite a bit better than no standard at all.

Re:Comparison

[2.7182]

There is a lot of hype in the news about chaos theory, but as an applied mathematician I don't see many applications of it. There are a lot of theories as to why it fell, but, in my opinion, chaos theory is neither useful in such a case, or even applicable. If you ask people concrete questions like "what would you actually calculate using chaos theory to show this", I never get an answer.

By definition, chaotic systems are sensitive to initial conditions, so small changes in the intial states make big long term changes. This has been a problem in using the idea of chaos to simulate real systems - noise matters a lot.

Re:Comparison

[guet]

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.

Re:Comparison

[Alioth]

Well, that's if time was running backwards - the Tacoma Bridge collapsed 8 years before the 1948 standard...

Re:Comparison

[wrygrin]

> 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.

that misses an important aspect of software development. many of the hard issues are not about fundamental algorithmic principles, but about supporting development at the frontiers of what's being developed.

software is an intrinsically compositional art, so that the frontiers and even criteria for standards are constantly (and sometimes erratically) shifting. *that* is where many of the challanges in software standards lie - each choice you make precludes some avenues, and some of the time those other avenues are going to prevail, despite your expectations. the software standards landscape is littered with failed standards, just because things turned in different directions than anticipated, for many different reasons.

yet, waiting to see how things shake out before declaring a standard can lead to fragmentation and missed opportunity. the art, as i understand it, is in choosing the place and time to take a stand, and gathering salient input so that you make choices that will support the best opportunities - for intricate notions of "best"...

Re:Comparison

[ediron2]

[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.

Software...
(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.

Re:Comparison

[Cal Paterson]

But let's be honest, it's pretty obvious to anyone that the MS XML format is shit now. Forget the far future; I don't want to use that today!

Re:Comparison

[statusbar]

Obviously it did not collapse because of chaos theory then! It collapsed because of the time-dilation pressure caused by it going backwards in time!

--jeffk++

Re:Comparison

[Elektroschock]

What about the year 2000 bug?

Re:Comparison

[Fred_A]

There is a lot of hype in the news about chaos theory, but as an applied mathematician I don't see many applications of it.

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

[poopdeville]

The popular press uses "Chaos theory" as a blanket term for what mathematicians and engineers call Dynamic Systems theory, cybernetics, and a few other related fields. The field that corresponds to calculating the mode of destruction of the Tacoma Narrows bridge is called Catastrophe theory.

See http://en.wikipedia.org/wiki/Catastrophe_theory. I don't like their treatment, as I prefer it presented in terms of complex functions. (In the complex function case, a catastrophe is a singularity on a meromorphic function.)

Re:Comparison

[scottme]

IBM Workplace Documents runs on Windows and supports ODF - uses it as its native format in fact.

Re:Comparison

[Chris Oz]

At this point in time I think people misuse the term the term engineering when they talk about software develpment. It is really wishfully thinking rather than fact. Interestingly the reason people talk about software engineering is that engineering methods and practices are well respected. It is hoped that if these methods are sucessfully applied to software development then software development will achieve the same consistantly high level of result that standard engineering has achieved. Unfortunately this is not yet the case, but the industry is working on it. An interesting point of comparison is would you trust your life to version 1 of Microsoft's Bridge 2000. Probably not, however I suspect that you almost never consider the safety of the bidge you drive over or the building you are in or the piece of medical equipement ...

Hopefully not?

[fireboy1919]

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?

[albalbo]

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.

Re:Hopefully not?

[Amouth]

i am glad to see someone else whom sees the same light as me.. it makes me have hope in the world

Re:Hopefully not?

[DJCacophony]

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.

Re:Hopefully not?

[etymxris]

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.

Re:Hopefully not?

[jrumney]

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).

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.

Re:Hopefully not?

[fireboy1919]

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?

Re:Hopefully not?

[CRCulver]

I hate XML. It's not easy for humans to read as a wire protocol.

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.

Re:Hopefully not?

[Ernesto Alvarez]

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.

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.

Re:Hopefully not?

[AKAImBatman]

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.

Re:Hopefully not?

[YU Nicks NE Way]

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.

Interestingly, this is exactly one of the "technical flaws" that GrokLaw claims to have found in OpenXML.

Re:Hopefully not?

[albalbo]

Well, off the top of my head, here are a few things that XML can do that JSON/etc. cannot do:

• be obvious about what character set they are encoded in;
• be written in multiple languages at the same time, without a priori knowledge of which sections are written in which language;
• include tags/attributes from multiple DTDs within the one document via namespaces;

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.

Re:Hopefully not?

[fireboy1919]

XHTML is an XML technology, and humans can read it easily.

No. For example, I have problems reading this bit from an XHTML document: /* Compares I,J, and K and returns the greatest.
*/
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.

Re:Hopefully not?

[albalbo]

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.

Interestingly, this is exactly one of the "technical flaws" that GrokLaw claims to have found in OpenXML.

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.

Re:Hopefully not?

[cduffy]

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.

Re:Hopefully not?

[Anonymous Coward]

"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)."

Perhaps what you are looking for is lisp. It doesn't have the attribute baggage, It's easy to parse, It's easier to type, and it doesn't hold onto the artificial distinction between data and code.

Consider:
      <some_xml foo="1" bar="joe"><body/></some_xml>

      vs

      (some_lisp (foo 1) (bar "joe") (body))

Re:Hopefully not?

[fireboy1919]

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?

Re:Hopefully not?

[Amouth]

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

Re:Hopefully not?

[DJCacophony]

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.

Re:Hopefully not?

[Schraegstrichpunkt]

Speaking of CDATA, how do you represent the string "]]>" inside a CDATA block?

Re:Hopefully not?

[Anonymous Coward]

I'd hate to break it to ya bub, but that, by definition, was a comparison.

Re:Hopefully not?

[init100]

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.

Re:Hopefully not?

[albalbo]

The same can be said for any XML readers that don't support those formats. So?

That's exactly the point - all XML readers support these basic things, it's not format specific.

Re:Hopefully not?

[fireboy1919]

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.

What technical weaknesses in OpenXML?

[Anonymous Coward]

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?

[oztiks]

... I don't want religious crap, give me the real technical differences. ...

It is believed by the jewish faith that the real document format has yet to come

Re:What technical weaknesses in OpenXML?

[mrchaotica]

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.

Re:What technical weaknesses in OpenXML?

[DrXym]

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.

Re:What technical weaknesses in OpenXML?

[Kadin2048]

That I think is the biggest and most important difference. OpenDocument also implies the use of basically standard and also-Open formats like SVG for graphics, Dublin Core for metadata, and zip for the final compression. Who knows what formats MS will specify, or whether anyone besides them will have software to read the ancillary formats (embedded graphics, etc.). It will become yet another situtation of "if you just want to pry out the text, use any software; if you want it to look right, you have to use Microsoft software."

Microsoft only exists because of vendor lock-in. It's the be-all and end-all of their business model; anything that they produce is going to have a hook or hooks somewhere. It's not an unfair assumption, it's one that has many years of their products behind it: that's how they work, and it's what they do.

Re:What technical weaknesses in OpenXML?

[Just Some Guy]

What specific technical weaknesses are in OpenXML?

The fact that

<doc class="word">
<body>
<content type="randomEncoding">
RXZlciBoZWFyZCBvZiBzdGFuZGFyZHM/Cg==
</content>
</body>
</doc>

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.

Re:What technical weaknesses in OpenXML?

[alanQuatermain]

I believe that some information that will help explain this is to be found here. 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. However, OpenXML cannot do this: all text must reside within a tag, and only text or tags can reside within other tags. The article gives a textual example of this. To the computer, the MS one is probably closer to the internal representation of the data: object-oriented programmers will probably recognise the structure as an object encoding its member variables. However, it pretty much removes the benefit of using XML in the first place: source readability. If you look at HTML, it's fairly easy to change a couple words around, and make a few italic, or bold. But in the OpenXML format, that becomes a more laborious task.

The article goes on to make arguments which back up the basic premise given here. You can also see from the examples how the tags differ in type. They give examples in OpenXML, ODF, and XHTML. Just looking at the tags in the OpenXML source doesn't give you any real idea what they're doing-- I mean, what does <w:rPr> mean? However, the tags used in ODF are longer and easier to read and understand for a human.

Of course, you could say that human-readability isn't an issue, and that's a fairly valid argument. However, if human-readability isn't an issue, why use XML? Why not do what Office was doing before, and writing memory out to disk, or basically serializing the document object tree in binary? It'll be smaller and easier for the computer. The whole point of using XML is to make the data easily understandable to humans, to the point where we can make numerous (albeit potentially quite small) changes without needing a program to interpret the data for us. Or where it's possible for us to write an app that understands the data, which pretty much requires that we personally understand it. As it stands, just about any XML data format is quite self-explanatory in itself, which is why we have XML.

Maybe that doesn't answer everyone's questions, but I hope it proves at least a decent starting point.

-Q

Re:What technical weaknesses in OpenXML?

[quarkscat]

Isn't the real point that OpenXML is a valid document format just so long as no Microsoft-
defined documents are used?

Non-standard tags, as well as a proprietary (and patented) binary wrapper for Microsoft's
XML implimentation is IMHO enough to take MS products out of the running for any company,
government organization, or international body for use in long term document retrieval.

The EU is now doing to MS what the Bush administration's USA Department of Justice failed
to do -- financially punish Microsoft for an enduring and pernicious monopolistic pattern
of business practices.

That would be nice, but....

[j3one]

"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..

One word.

[Spy der Mann]

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.

Re:One word.

[blirp]

Interoperability

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.

This gives me more amunition.

[bogaboga]

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.

Re:This gives me more amunition.

[ZachPruckowski]

Why is that a troll? He's 100% correct. That ODF is certified gives people more of an impetus to support it. This will mean that OpenOffice/KOffice have a feature that MS Office doesn't, potentially fueling adoption.

Re:This gives me more amunition.

[Americano]

Definitely didn't deserve a troll. But I think what you're going to end up seeing is Microsoft will simply support ODF in Office. Yes, yes, they've said they won't. But if they start losing customers to OpenOffice, KOffice, StarOffice, and other competitors that support ODF, you can bet your ass that Microsoft will add support for ODF, and put one of those little "Would you like to save this in the Microsoft Office Default Format, which offers significant advantages over the original ODF specification," nag screens in. Then they can claim complete standards compliance, too.

Microsoft as a company has never struck me as a suicidally dogmatic entity. If everybody demands it, and they start losing their shirt in the office productivity market, they'll adapt and do what they need to to stop the loss. Since they can't "acquire & retire" OpenOffice or other open source competition, they'll have to change their software.

That's free market competition... and that's good for us lowly consumers in the long run. Microsoft cannot "kill" ODF, unless it release a clearly superior competing technical standard.

Re:This gives me more amunition.

[moochfish]

And then the CEO replies:

"ISO? But I think my Nero program can burn MS Word documents into ISOs..."

Re:This gives me more amunition.

[ElleyKitten]

But I think what you're going to end up seeing is Microsoft will simply support ODF in Office.

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.

[Antony T Curtis]

That's free market competition... and that's good for us lowly consumers in the long run. Microsoft cannot "kill" ODF, unless it release a clearly superior competing technical standard.

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 can claim that their product supports ODF but isn't their own format that much better?

Just the cynic in me typing...

Re:This gives me more amunition.

[Americano]

The other challenge is getting companies to upgrade to something with support for ODF, and start using ODF as an alternative to their entrenched investment in MS Office-format documents. My company does a pretty large amount of work with external vendors and institutions. If suddenly everybody at my company started using ODF, and trying to send documents to people outside the company in ODF, that would be problematic.

Something I don't know about, because I haven't really investigated at this point -- is there some sort of "batch" tool for .Doc -> .odf conversions? If not, that's going to be a huge advantage for the first "open" project that develops one... if I can only convert by file -> open -> file -> save as . . . repeated ad infinitum, then that's a big barrier to odf adoption in companies that produce literally thousands of .doc files *every day*.

Re:This gives me more amunition.

[Dan Ost]

No, Microsoft's position is actually pretty weak. All it takes is for one
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.

[Americano]

Perhaps... but I don't think the future's as bleak as your fears. Consider:

1. ODF is now a defined ISO standard.
2. Since a critical aspect of XML is that you can check to ensure that it is well-formed *and* valid, it should be possible to determine if a given ODF document is compliant with the ODF standard.
3. Some government institutions and other ogranizations are mandating use of ODF for all "critical" documents.

Given items 1 & 2, if a standard-compliant ODF file does not render properly in Office, then Office is *demonstrably* broken. By definition, Office would not conform to the ODF standard.

Given 3, any company wishing to do business with a government institution that mandates this usage of ODF has a vested interest in making sure that the ODF files render properly in their software.

Given all three, any tool that wishes to have a crack at lucrative government contracts had better make sure it conforms to the standard... and I don't see Microsoft ceding that segment of the government market to OpenOffice & KOffice.

Re:This gives me more amunition.

[Antony T Curtis]

Ok...

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.

[ElleyKitten]

Something I don't know about, because I haven't really investigated at this point -- is there some sort of "batch" tool for .Doc -> .odf conversions?

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.

[Americano]

You're right, no company would simply say, "Hey, let's switch over to Linux today!" But there's nothing preventing someone from porting that tool to work with OpenOffice on Windows... and a tool that converts from doc->odf and back would be a huge step towards lowering the barriers to a switch away from MSFT's proprietary formats.

Re:This gives me more amunition.

[Americano]

Only the determined... or the people mandated to use it (remember that gov't market...), who will complain LOUDLY that Microsoft's tool is wasting their time importing and exporting... which will then prompt government agencies to tell Microsoft, "If OpenOffice can do it in 15 seconds and you can't, we'll use their implementation." Again, it amounts to dollars & cents... does Microsoft spend money pissing off customers by inserting a "if (doctype == "odf") { then sleep(600); }" statement in their code, or do they spend their money on other things?

My money's on them providing "acceptable" support of the letter of the ODF standard (I won't claim that they'll provide robust support for ODF, they'll do the minimum possible to support it), and offering extensions & tools that do other "WOW!" things, with the caveat: "t oh... you have to use OfficeXML to be able to use those features, since ODF doesn't support them..." -- they've submitted OfficeXML to ECMA, so I'm guessing they'll cram all sorts of stuff into their OfficeXML implementation, and the argument will boil down to OfficeXML as an ECMA standard versus ODF as an ISO standard.

Re:This gives me more amunition.

[Antony T Curtis]

does Microsoft spend money pissing off customers by inserting a "if (doctype == "odf") { then sleep(600); }" statement in their code, or do they spend their money on other things?

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.

[moochfish]

Will we see a re-emergence of news related to the Massachusetts switch to ODF? Will this trigger more government branches to start considering other Office apps?

Re:This gives me more amunition.

[Americano]

Is this ~15 year example the most timely & relevant example you can think of? If so, I think you're really reaching for stuff here.

Re:This gives me more amunition.

[Antony T Curtis]

It is the most recent example of which Microsoft has inflicted upon myself. Soon after that, I was no longer a Microsoft customer. (except thought the illegal tying of DOS+Windows licenses to processors which occurred in the 486 and early Pentium era)

Re:This gives me more amunition.

[MrCreosote]

I wouldn't even mention ODF. Just say the format for storage of documents must be ISO/IEC 26300.

Re:This gives me more amunition.

[Bert64]

Openoffice already has a batch convert option by default.

Re:This gives me more amunition.

[Americano]

Okay, let's assume your hypothesis is true: Microsoft deliberately wrote crap code for OS/2 to push users towards the more pleasant experience of Windows. In that case, the crap code they wrote for a competitor's product (OS/2) drove business to their competing product (Windows).

Now consider your ODF-in-Office theory. By putting crap code in one of their flagship products, they will drive people to... what? Continue using their flagship product, but save in a different format? Give up Office completely and use OpenOffice, or some other competing implementation that allows them to use ODF without the hassle?

What you're failing to address is the simple fact that if MSFT wants government contracts where ODF support is a requirement, they'll be putting themselves at a huge disadvantage (or taking themselves out of the running completely) by refusing to support ODF, or supporting it in a way that frustrates or irritates users.

(And before someone comes along and says it, I'll strike pre-emptively: spare me the typical snarky slashdot-isms about how Microsoft already writes code that frustrates and irritates users. If there was an OS out there that didn't come with its own set of different irritations and limitations for users, it would displace Windows in milliseconds.)

Re:This gives me more amunition.

[Antony T Curtis]

You make an interesting point except that... "Microsoft OS/2 1.2" was Microsoft's flagship product at that time.
So your argument kind of falls flat on it's face.

Re:This gives me more amunition.

[Americano]

Yep. You're right. Because in the period between the release of OS/2 1.2 in 1989, and the release of Windows 3.0 in 1990, around which time the "divorce" of IBM & Microsoft occurred, I'm sure nobody at Microsoft spent ANY time thinking about what direction they wanted to take with their operating system. The whole thing was just a spur-of-the-moment decision gone horribly awry.

You've still failed to address the simple question of what happens when a particular body (for example, a government agency) mandates the use of ODF, MS Office doesn't support it, and someone else does? I'm failing to see how government contracts getting awarded to Sun, IBM, or some other vendor supporting an ODF implementation is just part of Microsoft's nefarious plan to profit by killing ODF.

Re:This gives me more amunition.

[Antony T Curtis]

You've still failed to address the simple question of what happens when a particular body (for example, a government agency) mandates the use of ODF, MS Office doesn't support it, and someone else does? I'm failing to see how government contracts getting awarded to Sun, IBM, or some other vendor supporting an ODF implementation is just part of Microsoft's nefarious plan to profit by killing ODF.

Government mandates typically stipulate that all product selections are products which have more than one manufacturer. That was one of IBM and Microsoft's goals when they both produced OS/2 - hence why there were both IBM versions of OS/2 (1.1, 1.3) and Microsoft versions of OS/2 (1.0, 1.2) ...

Of course nowadays, mandates are made to be broken. Windows is used extensively in the US Government, both military and civil, even though there is only one manufacturer: Microsoft.

It doesn't really matter what gets mandated by whom; there will be ways that a multi-billion-dollar bank account balance can side-step the rule. Microsoft is perfectly aware of this.

So much for the list of experts

[Viol8]

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

[Kadin2048]

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

[AKAImBatman]

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.

Re:So much for the list of experts

[Anonymous Coward]

Experts from the Society of Biblical Literature?? Wtf?? What the hell have they got to do with a computer data formatting standard??

That's kind of an arrogant thing for you to say. How much thought did you put into this? zero? yeah, I'm not really surprised.

Could it be *gasp* that the society of biblical literature has been creating massive, complicated crossreferenced documents for hundreds of years, and that maybe that have more value to add to this than a company like boeing? That you reject them out of hand says a lot about you.

Re:So much for the list of experts

[Kjella]

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) ;)

Re:So much for the list of experts

[ZWithaPGGB]

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.

Re:So much for the list of experts

[mrchaotica]

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).

Exactly -- religious organizations are used to trying to piece together tattered 1000-year-old manuscripts that were written in a dead language and with faded ink. They're certainly extremely interested in preventing the need to do the equivalent of that (e.g. deciphering a binary MS Word 2.0 document) again in the future.

Re:So much for the list of experts

[AKAImBatman]

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?

Re:So much for the list of experts

[jmorris42]

> 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.

Re:So much for the list of experts

[cduffy]

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.

Re:So much for the list of experts

[Cal Paterson]

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.

Re:So much for the list of experts

[Kadin2048]

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.

Re:So much for the list of experts

[init100]

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?

Re:So much for the list of experts

[The Warlock]

Have you ever heard of a euphamism before?

Re:So much for the list of experts

[Citizen of Earth]

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.

Re:So much for the list of experts

[AKAImBatman]

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.

Re:So much for the list of experts

[Kadin2048]

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.

Re:So much for the list of experts

[init100]

I guess I learn something new every day. Thanks!

Re:So much for the list of experts

[ZWithaPGGB]

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.

Re:So much for the list of experts

[Citizen of Earth]

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.

Re:So much for the list of experts

[init100]

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.

Whoa there, Mr. Snarky.

[biendamon]

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.

Re:Whoa there, Mr. Snarky.

[cduffy]

Hey -- how was I supposed to get the editors' attention without some offtopic comment? When in Rome, and all that.

(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.

[biendamon]

Personally, I'm not going to worry about that until it actually looks like there's a possibility of it happening... But I completely agree on getting the editors' attention. :)

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.

I think software is less well understood

[plopez]

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

Good news

[spectrumCoder]

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

[tomstdenis]

I'm writing a book in Word [yeah I know, shudder] and my 57 page 2nd chapter is about 340KB on disk. It sports 10 figures, lots of styles (from normal paragraphs, to emphasis to source code etc...)

Maybe you put high res graphics and are using tracked changes?

Tom

Re:Good news

[CastrTroy]

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.

Re:Good news

[Anonymous Coward]

Part of this has to do with the fact you can do this:

unzip filename.odt

Which I think was actually a pretty sensible thing for them to do. XML is quite verbose and can benefit greatly from even minimal compression.

Re:Good news

[CastrTroy]

Yes, because compessing a file is such an ingenios Idea. That's why when the text was 1 page repeated over and over again, the 300 page file was still 23 KB. With any written text it's a good idea to compress it, because langage is very redundant. Nobody says that MS isn't allowed to compress their files too.

Re:Good news

[xygorn]

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.

Re:Good news

[CastrTroy]

Maybe you can run PKZipfix on the document. I'm sure there's ways to recover it. Most users if the file doesn't open, then it's lost. If you aren't most users, then you could probably find a way to recover the data. If you're really concerned about losing your data you'll keep backups. Rellying on which format lets you recover the most is a bad way of ensuring you can recover you data. What happens if the whole file gets corrupt? Yeah, you should have had backups.

Re:One small standard for a man

[Red Flayer]

"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.

ODF makes sense

[MarkWatson]

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?

Re:ODF makes sense

[Viol8]

"doing and partly to support a good cause."

Err, yeah, right, whatever. I mean obviously millions are worrying about the
data format of word documents and I heard that even Bono discussed it with
major world leaders and the Pope recently , but personally if I'm going to
support a good cause I got for stuff like oxfam or the red cross or cancer
research. Call me old fashioned if you will.

Re:ODF makes sense

[squallbsr]

Who would want to build systems around Office formats?

Chills just ran up and down my spine!

Re:ODF makes sense

[MarkWatson]

my wife and I donate to Heffer project, Habbitat for Humanity, and the American Friends Service Committee (AFSC) every month with automatic credit card payments

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.

Re:ODF makes sense

[ratboy666]

Because nobody builds around MS Office formats. That would be foolish.

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 Microsoft, because the hooks at are such a high level. Which makes MS Office a "platform" to base certain kinds of development on.

After all, being able to control Excel as a spreadsheet component directly is much more useful than being able to just write a compatible Excel spreadsheet file. It also provides integration into the platform, and automation.

Indeed a sanctioned way to generating MS Office files is to write a importer in VB Script, and produce the document from that. You need to know NOTHING about the "MS format" to do this.

Good? Bad? I don't know. As an MS shareholder, I find it interesting, though. As a Unix developer, I wish that there were open source CORBA (or whatever) bits to let me move MS systems around to differeent platforms (not in Microsofts interests, so I guess its not happening).

As usual, YMMV.

Ratboy.

Re:ODF makes sense

[MarkWatson]

I could really agree with you except for one thing: what guarentee do you have that a Word or Excel file that you create today and archive will be readable in 10 years? I suppose that an archive strategy could include exporting the original documents to test, CSV, etc., and archiving the original and text copies.

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 code snippets to access OpenOffice.org or AbiWord diocuments - pretty much trivial.

Anyway, I am not saying that you are wrong - I am just stating my own preferences.

Re:ODF makes sense

[Anonymous Coward]

Less important != not important at all. There's space for plenty of good causes in the world, great and small.

Re:ODF makes sense

[RobertLTux]

okay so would you like the Red Cross to have to spend US$(bignum) to recover data from Microsoft one day just "deciding" to do a lockout of all Red Cross owned computers?? thats what Trusted Computing means. or how about the whole Katrina data issues??

Formulas?

[Makzu]

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.

Re:Formulas?

[testerus]

standard proper about how formulas (for spreadsheets) should be stored and used Thats what OpenFormula is all about.

"human point of view"...

[CarpetShark]

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.

Showing my ignorance here...

[hcob$]

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!

Re:Showing my ignorance here...

[Secrity]

AFAIK; if somebody tried to extend an ODF format by adding extra things that were not approved by the ODF people who would approve of such things, then the resulting format could not be considered to be an ODF format. It isn't much different from what Microsoft is trying to do now.

Same thing?

[Anonymous Coward]

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.

Re:Same thing?

[Anonymous Coward]

MathML, wasn't it?

Re:Same thing?

[cortana]

Not yet, but it is being worked on: http://www.oasis-open.org/archives/office/200602/m sg00030.html

"technical weaknesses" ?

[Rolf Tollerud]

ODF is 5 to 100 slower that Microsoft Office. http://blogs.zdnet.com/Ou/?p=196

Re:"technical weaknesses" ?

[animaal]

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" ?

[dubonbacon]

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

Blah-blah buzzword blah-blah-blah

[Anonymous Coward]

MathML, wasn't it?

Except no ODF spreadsheet uses it. Next, please.

mathML sucks.

[zippthorne]

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.

Re:mathML sucks.

[EvanED]

You might look at http://www.mathmlcentral.com/Tools/ToMathML.jsp

It appears to take Mathematica syntax and give you MathML. I can't vouch for its accuracy or completeness.

Re:mathML sucks.

[Anonymous Coward]

Yes, MathML sucks. But they're talking about spreadsheet formulas, not math markup, in this context.

Re:mathML sucks.

[zippthorne]

Yeah I've used that. That's how I know that even simple formulas take up a huge amount of markeup with mathML. completely unnecessary markeup. They should've just used the "mathematica" format as the format since it's much more concise. make the tag something like,

<equation img="sparea.png" eq="4*pi*r^2" lang="mathematica"> area o' sphere </equation>

the mathml equivalent?

<math xmlns='http://www.w3.org/1998/Math/MathML'>
  <mrow>
  <mn>4</mn>
  <mo>&#8290;</mo>
  <mi>pi</mi>
  <mo>&#8290;</mo>
  <msup>
  <mi>r</mi>
  <mn>2</mn>
  </msup>
  </mrow>
</math>

All that text to display FOUR glyphs.

Not technical, but business reasons...

[Svartalf]

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:Not technical, but business reasons...

[marcosdumay]

Technicaly, they are not the same. ODF is readable and easy to edit, OpenXML (open?!) is not.

Now, if you meant that both can be readed and written by the same parser, and have the same speed and documment size trade-offs, yes, that is true. But easy to read and understand are also technical measures.

Re:Not technical, but business reasons...

[Svartalf]

Indeed. But the problem is, trying to convince some that ease of human reading is an important technical distinction is not so easily done. Again, it's all down to us not understanding what the big deal is with Microsoft- unless they're trying to maintain a monopoly position, which might be problematic for them.

Feel the draft

[lastberserker]

Here is the draft of ECMA standard, enjoy its 2000+ pages of detailed info.

Mixed content model...

[Numen]

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.

Re:Mixed content model...

[albalbo]

Funnily enough, I know a couple of the authors do these kind of transformations all the time - your ad hominem argument just doesn't cut it.

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 the examples of the non-mixed model: they're more verbose, and it requires more effort to generate. The mixed model is the least-effort model, yet - contrary to what you say - is not "ambiguous"; it's as exact as the non-mixed model.

Re:Mixed content model...

[Numen]

I'm sorry but while you might be able to cite people that you *know* that do this all the time, and be happy to give your conclusions based upon what *they* do.... *I* do this all the time and I'm basing my conclusions upon what *I* do.

Manifests are more complex for very good reason. They represent a point of refactored, decoupled extensibility... mainifest can be swapped in causing all references to point to different resources... if your data is being staged then this is a big deal.

Mixed content models are not easier to resolve. The intermediate text nodes are still just that... nodes. Now however they're simply unmarked text nodes and you must reference their context.

Not Chaos Theory

[TheOldBear]

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.

word of the day

[Anonymous Coward]

Is "sabatoge" something Microsoft-specific or did you mean sabotage?

MOD PARENT UP

[I'm Don Giovanni]

Finally, someone that uses objective analysis rather than religious doctrine regarding this issue.

Who are you kidding?

[einhverfr]

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.

Beatting a Dead Joke...

[soloport]

A simpler explanation: Before the meeting started, they cleared the room of all chairs.

;-)

Circular Arguments are not a technical weakness

[HighOrbit]

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.

Re:Circular Arguments are not a technical weakness

[mrchaotica]

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

Actually, my point was the bit about how ODF is implemented in a bunch of stuff (OpenOffice, KOffice, Abiword, that IBM software, etc. while OpenXML is only in MS Office. Therefore, using OpenXML would be stupid for the AC's company because it would lock them into only using Microsoft's software.

Also, although saying "OpenXML shouldn't be a standard because it isn't already a standard" is a tautology, it's still a good reason -- there's no point in having two standards for the same thing, you know!

Word document horror stories.

[Kadin2048]

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.

It weighs in at (drumroll, please) ... 275 KB.

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 .... that's a lot of wasted disk space thanks to an inexplicably bloated template document.

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.

Re:Word document horror stories.

[tomstdenis]

It probably has a lot of meta data in it like changes, styles, fonts, etc.

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 half decent grammar checker and perdy GUI...

Meh...

viva la ODT!

Re:Word document horror stories.

[Zaiff Urgulbunger]

The spooky thing is, if you load your MS document into OpenOffice.org and then re-save it out (Save As) as an MS Word .doc, the resulting file will be smaller.

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.

Re:Word document horror stories.

[jbengt]

You might think it's not tracking changes, but internally it still may be. I had a two page document that I played around with; adding and deleting jpgs, moving them around, trying to figure out how to get the required layout. At the end I deleted all the pics and saved. The doc was 900KB! Even after reopening, modifying quite a bit and saving it, it stayed huge. I'm guessing that it was saving the jpgs in the undo queue, even when they were no longer available to undo from the undo button.

patents

[Elektroschock]

Patents e.g. http://gauss.ffii.org/PatentView/EP1376387

This needs to get discussed first.

Re:One small standard for a man

[Slithe]

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.

KOffice will run on Windows very soon

[ingwa]

What is remaining for ODF to be healthy standard - is competing implementations. KOffice is limited to KDE which doesn't run under Windows.

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.

Re:KOffice will run on Windows very soon

[Bert64]

Koffice already runs on windows, but older versions of qt on windows require a commercial license so you need to buy the windows version of koffice...

Re:One small standard for a man

[Red Flayer]

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?

OOo != ODF

[Anonymous Coward]

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.

Question on best document format

[failedlogic]

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.

Re:Question on best document format

[mcphail]

Using ODF is not an answer to your typesetting conundrum. Applying styles sensibly in a wordprocessor like OpenOffice Writer is a difficult skill. The format you store the document in has little influence on this.

I'd suggest using LyX to produce formal documents. It handles the typesetting for you, can manage bibliographies and create contents pages, references etc. The built in documentation will guide you through.

Re:Question on best document format

[Anonymous Coward]

Thank you! I kinda forgot about Lyx. Nice that there's a Mac binary for it as well. Since I have the summer to figure something it out, I'll give it a whirl. It will be very handy if it manages my bibliographies too. I can't say I'll use the math typesetting much but its a nice feature if I need some stats in my papers.

HTML today isn't so bad

[mstahl]

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.

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.

Hey, wait a moment...

[charlieman]

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

Reminds of something

[p.rican]

I read in someone's .sig

"The good thing about standards is that there's so many to choose from..."

Why not extend XHTML to support missing features?

[fprog26]

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>