[odf-discuss] plug-in and ODF 1.2 (was: Miguel on OXML)

[Peter Vandenabeele]

On 2/2/07, marbux <marbux at gmail.com> wrote:
...
> myself, I will append a private email from Gary Edwards to Peter and
> me that addresses the issue more eloquently than I can.

Thanks a lot for bringing this discussion to the open :-) This will allow us
to understand the issues and find workable solutions for interoperability
between the different formats at hand (which will not be easy since
at least some of the legacy formats contain "black boxes").

Check out the paper on this topic of Peter Strickx will present tomorrow
(3 Feb 2007) at Yale:

  http://research.yale.edu/isp/eventsosis.html


<disclaimer: my personal view, not an official standpoint>

I am not sure if I would want to advice to use the approach of enshrining
"black boxes" (pieces of data for which the detailed specification is not
known to the group of users that need to process the document) into
ODF or any format that is used for forward use or long term storage. As
I understand it, the entire goal of adopting ODF in Belgium was to use it
as an open standard for interoperability. That means:

* "open spec": fully specified
* "free spec": freely implementable (no inhibitors to implementation, also
   by Open Source SW; so that also enforces the use of RF license and not
   RAND)
* "open standard": adopted by a major international standards body
   (such as IETF, W3C, ISO, ...)

I doubt if an ODF document containing "black boxes" should be qualified
as conforming to the "Open Standards" definition (failing the first criterium
of fully specified), and thus not allowing 100% interop with all applications.

I can understand the needs of "subsets" and "extensions" for specialized
cases, but in both cases, everything that is in the ODF file is clearly
specified (e.g. in the case an extension is required for specialized
applications in the organisation that extends the format).

My opinion remains that the only fundamentally correct solution for interop
with legacy (partially non-open) formats is to have specialized applications
that understand these legacy formats (such as MS Office) convert them to
true Open Standards formats, without the inclusion of any "black boxes" in
the result. If that is not possible (e.g. because the MS Office application does
not provide this functionality, or a plug-in could not convert all
features of the
original document to fully specified ODF) and documents need to be
maintained "Copy Exact", why not simply leave those documents in their
original format or convert them to PDF or PDF/A for archiving ?

If they need to be used in the future for editing (and not archiving),
then maybe
we should bite the bullet at once and do the manual conversion to a true Open
Standard such as ODF (without black boxes). That is actually the approach I have
seen at the political cabinets of the Brussels local government agencies when
they fully migrated to OO.o as the uniform word processing application. They
manually converted the important templates to new and clean ODF templates.
But now they are fully on OO.o and have a set of cleanly designed ODF templates,
which has a lot of value to them. They have left the old documents in their
legacy formats and have left a few computers with legacy applications to view
those old documents with 100% fidelity if needed.

Allowing "black boxes" in ODF 1.2 risks adding a third class of documents:

* the currently dominant non-open formats
  (legacy MS office, WP, ... documents and also some new MS Office documents).
* fully specified ODF (where all bits of the ODF are fully specified)
* ODF with "black boxes"

Particularly, if e.g. all ODF documents for text have the .odt extension, how
then will we know which .odt documents are fully specified and which contain
"black boxes".  I fear grand confusion over this.

I am standing to be corrected.

<disclaimer: personal opinion/>

Thanks,

Peter