On Wed, Dec 13, 2006 at 10:09:54AM +0100, Georg C. F. Greve wrote:

|| On Tue, 12 Dec 2006 23:43:53 +0100 || Max Moritz Sievers mms@fsfe.org wrote:

mms> If so, the campaign against OpenXML could be combined with a mms> campaign advocating the use of descriptive markup.

My proposal would be to work for Open Document Format (ODF), which may include pointing out to people that OpenXML is neither a standard, nor an open one, but should not end there or have its focus on this.

Buf, this must be my longest post yet just to say "i don't know". I hope at least it's fun, which does not mean it's false.

My impression is that we'd better start teaching about what Max proposes, even more than precisely about OXML or ODF. It's both more difficult and more useful in the long term. I think the root issue is featuritis and people still thinking sending electronic documents is like sending sheets of paper.

When they get to know the minimum notions to understand why ODF is a better idea than OXML they should be able to understand that it is really good news that there are few ODF documents in the web, because HTML is much better than ODF for web publishing (although I'm going to vote for Alex's bug if I can, I don't want web servers to be unable to correctly serve ODF, I want users to understand posting HTML is much more useful 99% of the time).

Even assuming that OXML wasn't controlled by one vendor, there is no point in sending a document in a format that specifies so many features that only programs with the same huge feature set can use it. It's only use is to store the document in the same computer for later editing or printing. Once you change that computer's software or move the document to another computer something is likely to be different and it is likely to have some result (margins wrong on another printer, colors ugly in another monitor, fonts replaced in another system, whatever). So users need to understand the less features you use the more devices and systems you are likely to be able to use with the file (meaning the more time into future you'll be able to use it too) and they need to use the features only when they are needed.

And in order to use descriptive markup you need to understand a bit the markup and write the document with an open mind about where it is going to be displayed. You don't need huge expertise, just a little knowledge and the right mindset (something like "let's communicate something" instead of "let's take a sheet of paper and see what we put on it"). Otherwise, even if you have been convinced of adhering to standards, you get those nice HTML dumps of MS Office files. Maybe OOo does it better, but still it is not the proper way to write HTML, thinking in terms of paper.

Many people don't get the notion that there are different formats, and they can serve different purposes, and the task you want to achieve is not the same when you just want to print something and forget about it, or keep it to edit and reuse it for a long or short time, or post it or send it to others, or take it with you for use somewhere else....

I don't think it's so difficult, but it may take a generation until the bulk of people internalize these things. And before that time, it is very difficult that they understand anything at all about interoperability or open standards. If you think about interoperability lacking that background you're likely to end up asking for magic: you want everything exactly like it was at your desk (even the same ashtray in the same place next to your computer), even when you're accesing your files in a mobile phone. OXML will get closer to that magic (only in a few systems that are similar enough, which defeats the purpose of interoperability, but you can't understand that until you understand there are different systems and devices and capabilities and for a good reason). ODF will get less close (although on a wider range of places) and plain text will get furthest from your goal (but everywhere). In other words, you want to get fidelity from interoperability, not ubiquity. You can't get the max of both, it's a compromise but you don't know. So you'll never get open standards.

So I thing the debate is more about teaching than about coding. I think OOo support for .doc has done some good in allowing some migrations, but marketing of openoffice telling people you that you can use .doc files with it, and hiding the fact not only that you don't get 100% fidelity but the more important fact that you can't get it has done a great misservice to geting people to grasp the more basic intuitions they need to value freedom in their data. So the huge effort taken to achieve something that can't in principle be achieved, compatibility with a closed format, cuts both ways.

For me the problem is not putting the feature in or not, it probably makes sense to put it in if you already have .doc support (teleology apart, isn't OXML slightly better than .doc, isn't a X thousand published specification better than no specification, if it isn't why has MS waited so long to produce OXML?). The huge problem is how you sell it. I'd like to see that feature with some user interface like :

"Good morning. I'm sorry to see you're trying to open an OXML document. It's a though task you're facing, madam. That format has so many features that you'll only be able to use those files in places that happen to have all those features, which are so few it means you will be hardly able to use that file (not in a different computer, not in your computer at a later time when you've changed something, not in a device that could serve you well but is not quite a PC, not in some third party system your friend or coworker needs to work in at the moment it needs your document). I can try to read it and use it with my own features as well as I can. If I succeed with my features then it likely means the document needn't be in this bloated format in the first place. If I don't then it means the document is preventing you from choosing your software freely. I can try but the right solution is to create your documents in another format and to ask people to send documents to you in open standard formats, so that both of you can choose your different systems freely and still interoperate on the gcd of your systems features. Go here or address someone here for more info: <URL>. Since supporting bloated, one vendor formats is so deceiving this functionality is disabled by default. Do you really want to enable it or do you want to try to get the file in a more useful format ? Oh, and click here for the credits because it takes a lot of effort to get this necessarily unreliable functionality working the least bad as possible."

And then after a few days after the user ticked "don't show again" show something similar (yeah, nasty). When you open the file show a fearful list of unsupported features. When you save in a format that is not an open standard warn that who knows what other software may make of this file, poor thing, why are you treating it like this?. Heck, put the documentation team at documenting best practices to migrate to open standards, put the marketing team at communicating this instead of "buy OOo and magically access all kinds of files, even if nobody knows how they should show because the format is secret and unspecified and the vendor of the software that produced it isn't even able to make them work in all their products. OOoh ! OOo opens MS Office files better than MS Office itself ! Get snake OOoil and stop bugging people about standards.", get the public angry at the rude sender of the file instead, at the unilateral drafter of the standard, and not at OOo when formating breaks. And let the coding team implement the feature if they don't have anything better to do.

And if you think a word processor is not an educational package or a speaker's corner, think twice. Anything you use 8 hours a day is going to teach you things, try at least that it teaches you good things.

Unfortunately I have no idea how you get a marketing team,etc. at doing this, specially since there are going to be marketing teams working for companies that don't share your goal. In fact the marketing efforts I have seen closer to that mokery haven't been OOo official moves, but good-meaning ignorants trying to help. But this same argument applies to anything you try to say about whether the feature should be included or not in a free program.