[wilhelmtux-discussion] A free document format for document interchange?

Nicolas Iselin nicolas.wilhelmtux at iselin.ch
Die Jan 14 23:43:16 CET 2003


Am Dienstag, 14. Januar 2003 13.00 schrieben Sie:
Dear Robert,

>
> I was musing about a toally free Document format, for interchanging
> documents, and I came up with the following postulates:

I think you put too much into it. I support very much
the arguments of Manfred Morgner: The format should be as
simple as possible. 

>
> - It must be possible to ipmlement viewers and creation tools without
> paying license fees (please note, I dont say free here, I say
> royalty-free)

Full ACK. I would even add that it should be ok to put
the source code for viewers/writers in the public domain.
>
> - The format should support both editable and non-editable content

Is this really necessary. Why not two different formats. I
like the unix philosophy: One tool for one task, and I 
would extend that to formats. 
>
> - The format should allow trustworthy content (public-key crypto
> signing/encryption/trust)

No, this is a separate feature. You can encrypt any byte
stream with separate tools. Why not have a simple format
and then encrypt/sign/... the file ? What is the bonus 
of integration (I would even say mixing) two features that
are basically independent ?
>
> - The format should embed all used fonts
>

This is only necessary for reproducing the document on
paper. And even there: It makes the format too complex.

> - The format should allow integration of non-textual media (images,
> sounds)

Images, yes, maybe. But sound ? 
>
> - The format should ont allow the execution of macros or scripts
> (java-like sandbox model)?

Although having code and data in the same memory is one of
the central aspects of the VonNeumann-Architecture (after which
most modern CPUs are built), the mixing of code and data in 
single format is _THE_ source of the virus and other security
problems: As long as a mail was just _printed_ ascii text,
it was impossible to create an email virus (except in 
attachments, of course), because the mail was always just
printed, not executed. Nowadays, more and more people
(unfortunately) use HTML for their mail. And as soon as you
have Java-Script or other 'active' content, you risk the
integrity of your machine. The same goes for .DOC with
Macros in it.

>
> - The format should support Multibyte Charsets (Farsi, Japanese,..)
>

It should code in UTF8 ?

> - Tools should exist for different platforms (at least Windows, MacOS,
> and Unix-Derivates)
>

Theoretically not necessary, but...

> - It would be nice if the format was XML-Based, with a public DTD.
>

Makes sense.

> - It would be nice if the tools saved in a compressed format (zip,
> bzip2,..)
>

Agreed. But not really necessary.

Nicolas