Page layout vs. descriptive markup

[Xavi Drudis Ferran]

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