[odf-discuss] Microsoft wins prize for "Best Campaigner against OOXML Standardization"

[marbux]

On 10/2/07, Peter Vandenabeele <peter at vandenabeele.com> wrote:
>
> On 10/2/07, marbux <marbux at gmail.com> wrote:
> ...
> >It
> > is error to portray ODF as a set of formats designed for
> interoperability.
> > It is not.
>
> An interesting discussion developed near the end of the session where
> certain
> participants (including myself) argued that we should strive for better
> interop
> between the different applications. In my vision that means catering also
> for
> those customers that want _less_ features, namely only the features that
> are
> supported on all the applications that they want to interoperate.Thatmeans
> defining a subset of ODF. For clarity, this is a pure SUBset, where each
> and every feature is defined in the spec, but some features are
> intentionally
> not used.


There's a need for one preceding step on that approach, which is to declare
a base superset of the ODF specification for interop purposes; i.e., every
conformant app should be able to be set to default to writing to ODF without
any extensions (the base superset) or a subset thereof.  This would
necessitate that vendors remain free to extend the specification, but files
containing any such extensions would need to contain a flag so the user can
be alerted to a file that may contain formatting that cannot be rendered by
the application in use.

>From there you can have subsets that do not need to be formally declared in
the ODF specification and have them automagically processed by more
featureful apps using profiles. E.g., if OOWriter opens a file generated by
KWord, the user could have OOWriter set to automagically limit its feature
set to those features supported by the app that generated the file, in this
case by reading a registered profile of the relevant KWord version's
capabilities.

This is the approach taken by the W3C's new Compound Document Formats
("CDF+"). You can get a good quick look at the approach in the conformance
section of the Compound Document by Reference Framework, e.g.,

User Agent Conformance
> >
> >    1.
> >
> >    User agents must allow the child DOM to access the parent DOM.
> >    2.
> >
> >    User agents must allow the parent DOM to access any child DOM. The
> >    contentDocument attribute must represent the child document.
> >    3.
> >
> >    A conformant user agent of a superset profile specification must
> >    process subset profile content as if it were the superset profile content.
> >
> > So CDF+ has a built-in round-trip conformance requirement for
interactions between less and more featureful applications. And the CDF+
interop framework has the additional advantage of potentially enabling
round-trip interop among apps that support any file formats that can be
profiled. So assuming that the interop warts were removed in both ODF and
Ecma 376, documents could be round-tripped between the two formats using
CDF+ as the intermediary meta-language. That's one of the big reasons that
we chose CDF+ for our development work, allowing us to move forward with our
interop work yet still keep options open to work with ODF and Ecma 376
should their respective TCs every get around to fixing their interop warts,
perhaps by adopting the CDF interop framework as their own.

This isn't the only way round-trip interop can be achieved and I think the
approach would best be supplemented by another akin to the WordPerfect
method that allows round-tripping even when files superset the base
superset, but we think the CDF+ approach the core approach that best
addresses market requirements, allowing both interoperability and
innovation. It sets no threshold for the number and types of elements that
must be supported by a conformant application, meaning that apps can still
round-trip interoperate and compete regardless of whether they ever become
full-featured. (E.g., Thomas Zander could achieve his dream of being able to
open a KWord document in OOWriter to do something he can't do in Kword and
then move the document back to KWord without data loss.)  And developers are
still allowed and even encouraged to innovate with extensions by the
WordPerfect-like round-tripping method. But the CDF+ approach allows offices
that wish to standardize upon a feature set to do so, so long as they can
find developers willing to support a profile for the particular feature set
desired.

The next question then is, for which applications that subset should be
> defined.
> Amongst a certain group, a consensus developed that (now that Microsoft is
> still dominant in the market of "Office" applications), we should
> strive for better
> interop with that dominant player.


That's reality. Microsoft has 95 per cent of the users locked in. ODF apps
either become interoperable with MS Office or ODF will die.


The solution I and some others defended was
> the (existing) idea to define (formally inside the standard or
> informally outside
> of the ODF standard) an interop subset that would interoperate better with
> Microsoft Office + Sun plug-in application combo. The next step then is
> for
> the ODF processing applications to have a flag by which the ODF processing
> application is set in "MS Office interop mode" so that it disallows
> features that
> are outside of this interop subset.


I haven't checked, but my suspicion is that Sun has not decoded the
Microsoft native file support APIs sufficiently to allow a compatibility
mode to be set within the Office apps. They certainly have not decoded the
Word API to the extent we have or there would be no conversion artifacts in
the ODF their plug-in generates. And given the extent to which Sun has
played dirty pool with us, we're not interested in helping them. Also, thus
far Sun has been adamant on the TC that it is unwilling to limit the feature
set in OOo for purposes of interop with MS Office. So I think what you seek
collides with what the company that controls the ODF TC is willing to do
unless Sun has had a sudden change of heart.


Obviously I respect that other customers of ODF processing applications will
> want to have maximum feature sets, or even their own company specific
> extensions. But the solution I defended at the ODF Camp is that at least
> those customers for which interop is more important then maximum feature
> set get a solution.


A laudable goal.

For clarity, I repeat that I do not believe that _adding_ extra unspecified
> "dark matter" to the ODF file is the solution. The solution is to
> _subtract_
> from the ODF file those 5 or 10% percentage of constructs that are
> accidentally difficult to implement in the current market leading Office
> application. In parallel, ODF processing applications can develop as much
> extra and new features as they like but preferably those can be turned off
> at the choice of the customer.


IMHO, you've misunderstood this issue from the very beginning. The plain
fact is that MS Office supports some features that have no equivalents in
OOo, and vice versa. See <http://odf-converter.sourceforge.net/features.html>.
And not everything the MS Word native file support APIs encode is completely
decoded. If there is any way to round trip documents without lossiness
between the Microsoft binary formats and ODF without storing the dark
objects in ODF, we haven't found it. It is not just an issue of setting a
compatibility mode in Office. If the dark objects cannot be restored on the
return leg of the trip, data lossiness sets in.

The ODF foreign elements and attributes were expressly designed for interop
with apps using legacy binary formats and storing dark objects in ODF files
causes no harm whatsoever to an ODF application. What we did with them was
precisely what they were intended for. But it is a stark choice between such
storage or lossiness in round-tripping until such time as all of the dark
objects are completely decoded or such time as Microsoft might decide to
fully support ODF itself. There are only a few such dark objects left. But
we cannot set a compatibility mode in Office to work around them because we
do not yet know enough about what their functionality is.

But please understand and accept that we have no ability to reprogram
Microsoft Office. We have to work with it in the state Microsoft leaves it
and the extent to which we can decode its native file support APIs.
Presently, there is only one alternative to parking a very few dark objects
in the files we cause Microsoft Office to convert its in-memory binary
representations of documents to. That alternative is loss of data.

It's largely an academic issue now as to ODF because we could not work
around OOo's destruction of the metadata for the dark objects and the
features not supported in OOo. Furthermore, Sun just won a TC decision to
allow them to block us from using RDF metadata instead to work around the
problem. We are no longer developing for ODF but continue to push on fixing
its interop warts so that we might do so in the future.

Let the customer chose between optimal interop or maximum feature sets.


There are ways to have that cake and eat it too.

Best regards,

BUCK "MARBUX" MARTIN
  Director of Legal Affairs
  OpenDocument Foundation
  Contact:
<http://www.opendocumentfoundation.us/contact.htm>
-- Universal Interop Now!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20071002/527e4232/attachment-0001.htm