[odf-discuss] Recommended reading: Rick Jelliffe on converging editable electronic document packaging conventions

[marbux]

On Tue, Jan 13, 2009 at 7:10 AM,  <robert_weir at us.ibm.com> wrote:
> Not sure what the benefit of this would be.  From an implementation
> perspective, writing code to support different ZIP+XML packaging formats
> is trivial.  It amounts to maybe 0.1% of the effort of supporting ODF or
> OOXML for an editor.  But if the XML inside the Zip is not harmonized,
> then the other 99.9% of the differences is what will cause you grief.
>
> It is like saying, I'll write a book in English and you'll write a book in
> Japanese, but we'll agree that the table of contents goes in front, right
> after the title page, and that amounts to the sum total of our
> "interoperability":  Might have some use if your application only looks at
> the table of contents and nothing more.  But for typical uses of office
> documents, e.g,, editing, viewing, etc., it is not a very compelling
> use-case and hardly seems worth the effort.
>
> IMHO, harmonization needs to serve the goal of document interoperability
> and not merely be the target of an intellectual tidiness fetish.

I'm sorry I didn't notice that Jelliffe had missed linking his
previous article from part of the first paragraph I quoted:  "I have
mentioned this aspect before, when talking about whether a file can be
ODF and OOXML and a website at the same time. Can it be ODF and XPS
and MARS at the same time?"

His latest piece would have been more understandable had he linked
that prior discussion.
<http://www.oreillynet.com/xml/blog/2007/07/can_a_file_be_odf_and_open_xml.html>.
(Note the partial buy-in by Bruce d'Arcus and Patrick Durusau in the
comments.)

I'm not a huge fan of the idea of packaging both an ODF and OOXML
version of the same document in a Zip, at least in the present state
of both specs. There's too much incompatible variation. Still I
suspect Jelliffe's concept could with some elaboration be a useful
step along the path to harmonization and then convergence.

But the concept of packaging together the editable and archival
version of a document, e.g., ODF plus PDF packaged together is
something Gary Edwards and I have been advocating for at least a
couple of years.

"Pixel-perfect" archival plus editable in the same package fulfills a
lot of needs presently unfulfilled; e.g., the needs of both those who
want to see precisely what the person at the other end of the
conversation is seeing as well as the needs of those who wish to edit
the document. Likewise, packaging archival with the editable removes a
lot of headaches from recycling of archived content, not to mention
the management of archival operations.

Likewise, adding a minimalist XHTML version of the same document to
that package dramatically extends the variety of apps that can process
the document, assuming there is a more universal packaging convention
implemented by the receiving apps.

Likewise, a full-blown word processor could package two versions of
the document, one in a supersetting profile and one in a subsetting
profile, e.g., .ODT and .ODT Tiny.

Jelliffe has been over several articles exploring the concept of
"adaptability standards" and "etiquettes" in the XML standards
context.  See e.g., for a more detailed explanation of the terms, Ken
Krechmer's "Standards Mark the Course of Economic Progress,"
International Center for Standards Research, University of Colorado at
Boulder (undated), <http://www.csrstds.com/fundeco.html>.  One example
of an etiquette is the "handshaking" step of modem < > modem
communications, where the two IT systems involved negotiate which
communications protocol they will use for the exchange of data.

With data storage, system memory, and communications bandwidth no
longer so limiting, there are good grounds to expect that adaptability
standards and etiquettes will evolve for different electronic document
standards. E.g., one might view XSL as a group of standards with
significant adaptability aspects.

With packaged XML standards, combining different markup language
versions of the same documents presents us with a Zips within a Zip
problem. Is the variability of the packaging convention within each
nested Zip really necessary, given the unpredictability as to
implementations of which standards will be packaged together?

In that context, standardizing the packaging convention makes a lot of
sense to me. E.g., why should browser developers be required to
implement a bunch of different unpackaging methods? It's a dimension
of variability among different standards that could be standardized
considerably, with variability only where there is a compelling market
requirement to be fulfilled by variation.

Jelliffe's article identifies some low hanging fruit for reducing the
future variability, emerging areas of consensus in XML document
packaging. He also identifies a few remaining areas of disagreement,
where there may or may not be a compelling need for variation.

I think there are fair grounds for debating whether packaging a
plurality of formats together is a desirable path to walk. But
Jelliffe is exploring more than an intellectual tidiness fetish.

-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>