PAX: Why OOXML and ODF are inadquate bases for a forward-looking gen

["Rick Jelliffe" <rjelliffe@allette.com.au>]

Neither ODF nor Office Open XML are adequate bases for a forward-looking,
general-purpose office document format.

This is because the needs for level-playing-field data-interchange and the
needs for full-fidelity native formats are diametrically opposed and
*irreconcilable* by any single schema. Level-playing-field data
interchange requires a limitation of the documents to features supported
by generator and consumer, and some ability for graceful degradation.
Full-fidelity native formats require complete implementation of
product-specific features, which well may be more than hints added on top
of a generic structure, but sometimes have to be in terms of the data
models of the particular application.

Furthermore, office formats embody some idea of application type (a "word
processor", a "spreadsheet") however in real life, only "follower"
applications fit into those moulds, while "leader" applications go boldly
into new areras.

For example, Adobe StructuredFrameMaker is a word processor but also a
structured document editor. Lotus has WP capabilities but also groupware
aspects. In Office, Word has desktop publishing, blogging and forms,
Powerpoint is moving towards simple 2.5D animation, Excel is moving
towards report-writing features.

Furthermore, different users have different needs. Professional users of
equations, bibliographic information, etc. have different requirements to
lay users. Why arbitrarily choose one when we can have both?

What would a better approach be? To allow and encourage modularity and
plurality at the base level. Take advantage of ZIP to have multiple
versions of information items. A ZIP file can be both ODF and Open XML and
an HTML archive at the same time; sharing common media files or even media
files in different formats. An application can save in its native format
for full-fidelity when the file is opened up in the same application next
time, but also save in some more general format for wider distribution. It
is not as if all the desktop applications won't support import and export
of all the leading formats in a year's time, when the kerfuffle has died
down.

Or an application can choose one format, but cherry pick data in other
formats as needed, if it is using a ZIP format that supports plurality.

Is this a silly idea? Well, there are very successful precedents: Apple's
fat binaries, mail in multi-part HTML and text, Open Type's packaging of
postscript and truetype fonts, and indeed the whole Internet stack with
its semi-loose coupling between layers.*

In other words, the current fuss about choosing between brand A and brand
B makes the fundamental mistake that either (or both) Brand A or Brand B
can be the end of the line and satisfy our needs. Now both ODF and Open
XML support various kinds of extensions, modularity and so on, but they do
so from the POV of "how can we support this monolithic application?"
rather than from the POV of "how can we support pluralistic applications?"

What is needed is to take ZIP and work out what extra conventions are
needed to support this kind of plurality. OOXML's OPC goes much further
than ODF in this regard, but it is still not adequate. Then once a proper
layering and modularity system is in place, to modularize ODF and OOXML
and XHTML etc to allow this kind of plurality.

I have some more ideas on this on my blog  "Can a file be ODF and Open XML
at the same time" if anyone is interested.
http://www.oreillynet.com/xml/blog/2007/07/can_a_file_be_odf_and_open_xml.html
I thought the name .pax would be a good extension name, to give the flavour.

People who think that the evolution of file formats for "office" desktop
applications somehow ends in 2007 will naturally think of the current ISO
process in terms of Brand A versus Brand B. It is a kind of panic attack.
But I don't believe for a moment that it is the end of history: the real
game we need to be playing is how to put the ducks into line so that the
kind of pluralistic system becomes the natural win/win position for
vendors and users.

Cheers
Rick Jelliffe

* Now one area where this idea has not worked well has been the the
ability in HTTP MIME to specify alternative content types. However, as
with character set specification, I think this is because the MIME header
level is the wrong place for this functionality: it needs to be a
fine-grain capability inside the resource and the resource-rendering
systems.

What is the practical ramification on ISO standards? It means that we need
to be moving towards much more fine-grained namespaces specific to
particular information units, and a refactoring of data to reduce the
amount of mixed namespaces in a file: for example, if a domain-specific
schema requires rich text in a field, that rich text should be in a
different resource to allow alternative implementations.

That kind of route is the only way that I can see us ever getting to the
state where everyone can be happy: vendors can innovate and compete on
features, end users can have intereoperability, integrators have the most
chance that the documents will include data in schemas they have already
coped with, expert users can have their requirements met without
overburdening lay users, value-adders can add their own niche-market
alternatives to the regular formats without breaking anything. Etc.  We
are getting really close to this, it is no a pipe dream or unrealistic;
the problem is how to get demand and support for this kind of .PAX
approach in a world where people are fixated by "OR" (my way or the
highway) rather than "AND" (I feel the urge to merge).