Subject: Re: GNOME Office and OpenOffice (fwd)
From: WJCarpenter (bill-abisource@carpenter.ORG)
Date: Thu Oct 26 2000 - 13:25:07 CDT
ash> could get some of their features eg. tables, same file format
Between you, me, and the fencepost, I don't really hold out much hope
that multiple large software packages can use a common *native* file
format. On the face of it, it just seems so unlikely to be successful
that I can't believe it is a serious objective.
It is difficult enough (but managable) to have upwardly compatible
file formats from release to release of any one given product, but who
could imagine even a single complex package anticipating their own
needs well enough to stick with the same format year after year?
Sure, file format changes are consider Very Serious Events, but they
still happen. They happen for a very good reason: people continue to
have good ideas and improvements on old ideas.
I suppose the thinking goes something like this... FnordWord decides
to implement feature FnordDoodle, and the very extensible XML-based
File Format of the Universe (*.FFU) allows FnordDoodle thingies to be
written such that GumpWord can ignore them as unrecognized. The
GumpWord folks can safely implement GumpDoodles (a re-implementation
of FnordDoodles) when they're good and ready. (You could replace that
"when" with an "if" for a lot of features.) Meantime, when
roundtripping to *.FFU, GumpWord has to either carry the FnordDoodle
info opaquely or it has to lose it.
Instead, I think the structure of the current AbiWord code base
actually captures the correct philopsohy. The *.ABW format is treated
like an import/export like any other. The real thing that AbiWord
deals with as an application is not any particular file format (not
even *.ABW), but the objects into which information in those files is
instantiated. The only magic about *.ABW is that AbiWord developers
have exclusive control of its format, which is very empowering. The
format of *.FFU will be controlled by disparate groups, and it is hard
for something like that to remain vibrant over time.
In case anyone is looking for examples of where this didn't work, two
well-known cases in point are X.400 and EDI. Both have industry
standard formats, both have rich "escape sequences" for
vendor-specific lattitude, and both have mini-industries of 3rd
parties who do translations from one vendors industry standard format
to another's. There's a lot wrong with the process that led to those
two standards, but in a world where anyone can fork and open source
code base for any private motivation, I don't realistically see an
outcome more promising than this.
As for the fate of *.FFU, I think its best case scenario is to become
the next generation RTF. I don't really know if RTF has significant
shortcomings that *.FFU can address, but the two meta-shortcomings I
can think of are (1) RTF is controlled exclusively by Microsoft, and
(2) RTF is text-based while *.FFU will be XML-based. There is
probably a strong advantage to a consortium-controlled *.FFU, but the
mere change from text to XML seems sort of ho-hum to me. (I guess it
could in theory enable an XSLT from *.FFU to *.ABW, and then a direct
import of *.ABW, but I don't know if in practical terms that wins over
just having a direct *.FFU importer.)
-- bill@carpenter.ORG (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
This archive was generated by hypermail 2b25 : Thu Oct 26 2000 - 13:22:20 CDT