Re: [oiic-formation-discuss] MARBUX POINT OF ORDER, OBJECTION, AND SUGGESTIONS No. 1

[marbux <marbux@gmail.com>]

On Mon, Jun 16, 2008 at 3:11 AM, Sander Marechal
<sander.marechal@tribal-im.com> wrote:

> To explain myself a little bit better: I believe that this committee's work
> is focussed on interoperability in the ODF world, building test suites and
> tools that help ODF applications become compliant with the standard and
> helping ODF applications interoperate with each other. I don't think that
> the committee's work includes the interoperability of ODF with other
> standards such as OOXML, CDF, UDF or even PDF and HTML for that matter.

You've have a very serious serious misconception. CDF is not a
standard that ODF apps could interoperate with. CDF is the acronym for
the Compound Document Formats Working Group, a working group at W3C.
That working group has one completed standard, the Compound Document
by Reference Framework ("CDRF"). The working group is developing
profiles for compound document formats using W3C markup languages, the
WICD profiles.

But my proposals deal only with CDRF, the interop framework.
<http://www.w3.org/TR/CDR/>.  CDRF is *not* a format standard
implemented by other applications that ODF implementations could
interoperate with. It is a not a markup language or set of formats. It
is an *interoperability framework.* CDRF is an *application and
format-neutral* specification that specifes:

[i]  requirements for development of compatible profiles of compound
document formats working from a core profile to progressively
super-setting profiles;

[ii] requirements for creating compound document formats (unnecessary
for ODF because ODF already *is* a set of compound document formats);
and

[iii] a set of processing instructions and conformance requirements
for round-trip interoperable processing of profiled content, including
requirements for round-tripping between implementations of the less
and more featureful profiles.

The only barriers to achieving round-trip interop between
implementations of less and more featureful ODF profiles using the
CDRF specification are: [i] the work necessary to devevop the ODF
profiles -- that everyone seems to agree are needed -- in conformance
with the  CDRF requirements for profile development; and [ii] the
minimal work necessary for developers to implement the processing
instructions specified by CDRF for the processing of profiled content
in conformance with the CDRF spec. Because CDRF was designed to be
application and format-neutral, there are no application or format
dependencies. CDRF is specifically designed to work  with any
combination of plain text-based formats.

Why does this matter? I want to experience in my lifetime, e.g.,

-- A triple pane outliner able to send an ODT to OpenOffice.org and
have OpenOffice.org process that document in a manner that OOo can
send the same document back to the outliner using only the markup
vocabulary my outliner understands.

--- A mobile device editor, Google Docs, KOffice, and OpenOffice.org
able to process the same document in a business process with edits at
every way point along the processing chain and back again.  I don't
want just round-trip interoperability. I want multi-trip interop
through a chain of different apps participating in a business process.

CDRF not only enables this kind of round-trip processing between less
and more featureful implementations; it requires it. Those are the
kinds of interop doors opened by designating CDRF as the interop
framework to be used for the ODF profile work. E.g., one provision
from the CDRF conformance section reads:  "A conformant user agent of
a superset profile specification must process subset profile content
*as if it were* the superset profile content."

I.e., an implementation of an ODF desktop word  processor profile
(more featureful) that opens a document generated by an implementation
of a subset ODF web app editor profile (less featureful) would process
the document as though the latter were the superset. The document can
then be edited in the more featureful app and sent back to the less
featureful app in a vocabulary the less featureful app can understand
and process correctly.

User options to switch a document being processed to any supported
super-setting profile or the full range of features supported by the
app (non-profiled) would break the round-trip, but would allow a user
to apply a richer vocabulary of markup to a document generated by an
implementation of less featureful profile. E.g., a user generates
rough notes using his mobile device editor. then opens the document in
his desktop word processor and switches to the full feature set of his
word processor to massage the notes into a polished report.

This is not a complete solution to the problem of round-tripping
between less and more featureful implementations because: [i] apps
that implement only a subset profile will still encounter documents
that were written to a more featureful profile; and [ii] any
implementation of a profile will encounter documents that are not
written to any profile and that contain app-specific extensions to ODF
allowed by the ODF standard. .There is thus a need for a compatibility
framework as well, markup and processing instructions for the
processing of unrecognized metadata. I will save that discussion for
another post.

Does anyone else have a concrete work plan to allow less and more
featureful apps to round trip ODF documents during our lifetimes? I'm
all ears to hear any better plan. But just saying the word "profiles"
does not address what is necessary to achieve round-trip interop
between less and more featureful apps. That takes an interop
framework, and why should we develop our own when W3C has years into
inventing that wheel for us? Just to create incompatibilities with the
W3C wheel? What other justification is there?

Who here is willing to speak against round-trip interop between less
and more featureful ODF apps? Both IBM and Sun did substantial work in
developing CDRF Both are helping build the WICD profiles W3C is
developing using W3C formats. Both companies have the expertise and
resources to implement this. Their representatives at this meeting
need only consult with their fellow staffers to confirm that this is
feasible, assuming they have not already done so. We are in reality
only discussing whether there will be a commitment to *achieving*
interoperability including interop between less and more featureful
implementations.

There was an argument raised against my CDRF proposal that OASIS
charters cannot specify the use of other standards in TC work. I offer
in response, Requirements 2 and 4 of the OpenDocument Technical
Committee Chater:

"2. it must be *compatible* with the W3C Extensible Markup Language
(XML) v1.0 and W3C Namespaces in XML v1.0 specifications,
...
"4. it must be *friendly to* transformations using XSLT or similar
XML-based languages or tools,"

<http://www.oasis-open.org/committees/office/charter.php>

Will the opposition now argue that the ODF TC's charter violates OASIS
requirements by requiring the use of other standards for compatiblity
purposes? Are there any more excuses for not requiring round-trip
interop between less and more featureful implementations of ODF? The
programming techniques for achieving such interoperability are
anything but new. What is new is an open standard that can be used
with *any* plain text-based formats. Was the IBM opposition to
competing standards and enthusiasm for harmonization and convergence
in regard to ODF and OOXML only only a tactic to be discarded when it
came time to deal with ODF interoperability? Will this proposed TC
reinvent the W3C interop wheel just to introduce incompatibilities?
The choice is between a standard and a double standard. (Sorry,
couldn't resist the quadruple entendre. :-)

Best regards,

Paul E. Merrell, J.D. (Marbux)

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