Re: [oiic-formation-discuss] Proposed Use case -- Interoperability in vertical and horizontal ODF markets

[marbux <marbux@gmail.com>]

On Sat, Jun 28, 2008 at 4:11 AM, Dave Pawson <dave.pawson@gmail.com> wrote:
> Round trip with an application that does not support ODF seems a dead end Paul.

Disagree. That's what the foreign elements and attributes parts of the
ODF spec were designed for. I think the you'll see the skeleton if you
use the RFC 2119 defintiion of "may" in regard to the conformance
requirements that the standard was designed around. It was never
intended as a blank check to create extensions for new features.

That compatibility framework was never finished because Stellent's
interop sharpshooter Phil Boutros left the company and the TC before
it was finished (he was back with Stellent the last I heard). What is
missing is standardized compatibility markup for preservation of of
foreign elements and attributes.

Floridan Reuter made three proposals to the ODF TC to fill in that
blank but never even got his proposals placed on the agenda due to Sun
800-pound gorilla treatment. But his proposals found life in Ecma 376
(OOXML) Part 5 (Florian is on both the ODF TC and the Ecma 45 TC). The
compatibility framework specified in Ecma 376 Part 5 is the ODF
compatibility framework for foreign elements and attributes fleshed
out with five generic attributes for specifying what metadata should
be preserved by implementations, machine instructions for the
preservation of extensions to OOXML.

> As above. If the other app doesn't support ODF that's a no go area as I see it.
> If you want to propose that, IMHO that's a feature request?

No. It's just part of the existing standard that needs fixed. And it's
fairly high priority in my mind. It's the only part of ODF that
standardizes the means of round-tripping between other formats. E.g.,
MS Office.has feature mismatches with ODF, both richer and leaner. If
you don't have a standard way for processing such conversions, you
either accept loss of fidelity or wind up with a bunch of different
ODF apps using different markup for the preservation of markup in the
round-trips between the in-memory binary representations of a document
and the ODF version of the same document.

And that kind of thing in effect: [i] grants each ODF implementation a
monopoly on its own markup for handling the round-trip conversion to
and from other formats; and [ii] creates an interop nightmare for
users whose apps don't understand each others' compatibility markup.

It's a mission critical item, particularly for ODF app integration in
the enterprise market, e.g., in a SOA. If there is no standardized way
of integrating ODF apps with other apps in business processes without
data loss, then the enterprise ODF app market just turns into a battle
between dueling compatibility markup for integration purposes.

So this is in effect a bug report on a broken part of the conformance
section, not a feature request.

>> There unquestionably is such a market requirement.
>
> +1.
>
>  This list is not the place to support it.

You're telling me you have a user's manual for this list? :-)


>> Rob also attacks the very notion of enabling, through the ODF standard
>> and the profile-related work on the OIIC TC, any non-lossy conversions
>> between ODF and other formats.
>
> ISO is starting to look at that. Not through OIIC though.

IBM seems pretty set on not letting SC 34 deal with that in regard to
ODF. Won't bother you with a bunch of links to prior statements, but
IBM has been quite clear about that and claims there are legal
barriers to SC 34 taking away maintenance of ODF from OASIS.

But either way, the last time I looked at the relevant SC 34
documents, the only thing on their roadmap is harmonizing OOXML with
ODF and not even a timeline. Nothing there about interop involving
other formats or interop between less and more featureful
implementations at all. That's purely a big vendor/mega-app show so
far.

If you're going to do profile work, which is what is proposed without
any detail, the notion of working from a constantly expanding superset
of features back to a core profile seems imptactical to me. That would
mean in effect that both ODF and OOXML remain big vendor-only formats.
To me, the compatibility framework for round-tripping between formats
has to be part of the core profile or the interop framework beneath
the core-profile. I.e., you have to have a standardized way for
dealing with both profiled content and tag soup content and it needs
to be at the foundation level. .

Let me know if you haven't read it, but I see real problems with
having a separate TC to do profile work if it's going to be wagged by
the ODF TC dog. Profiles are standards and have to meet all the
requirements for standards. To me, this TC's profile work either waits
until ODF is fixed or it has to break compatibility with ODF. And even
if ODF is fixed for the superset, you still have the problem of it not
being designed for subsetting profile work

In other words, if compatibility with ODF is a requirement, the
profile-related work should be done on the ODF TC rather than in new
TC that has no control over the ODF spec.

Best regards,

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