OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [oiic-formation-discuss] Interoperability versus Conformity

On Mon, Jun 9, 2008 at 8:45 PM,  <robert_weir@us.ibm.com> wrote:
> Paul, this is not JTC1,

I didn't say it was. But you quoted from the same page of JTC 1
Directives in this conversation yourself, although you identified your
quotation as "ISO lingo" rather than citing to the Directives you
quoted from:  .

More importantly, are you excluding at the outset that the proposed
TC's deliverables would not be submitted to JTC 1 for approval as an
international conformity assessment procedure? The page we have been
quoting from is inextricably intertwined with JTC 1 Directives
requirements for conformity assessment procedures. If the work of this
proposed TC is to acquire no status beyond that of an OASIS standard,
the ODF international standard is left without formally approved
conformity assessment procedures.

and the proposed TC cannot change a single line of
> the ODF standard.  So I think the vast majority of your concerns are
> misdirected in terms of the present discussion.  In particular, rewriting
> ODF in terms of CDF is most certainly out of scope for this new TC.

The preliminary statement of scope for this proposed TC includes these
three clauses:

"2.	To provide feedback, where necessary, to the ODF TC on ways in which the
standard could improve interoperability;


"4.	To define interoperability with related standards by the creation of
profiles or technical reports;


"The IIC TC may also liaise with other standard bodies whose work is
leveraged in
present or future ODF specifications. These include, but are not limited to, the
W3C and ISO/IEC JTC1/SC34."


Moreover, you said in this same thread,

"Remember, none of this changes conformance at the level of any of the
ODF standards.  *But a profile is a standard, and can define its own
conformance."* <http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00067.html>.

So I do not see it as a valid criticism when you say that "the
proposed TC cannot change a single line of the ODF standard." Of
course we may not countermand existing conformance requirements in the
ODF standard. But there are virtually no conformance requirements in
ODF beyond the requirement of validation against the schema after all
foreign elements and attributes are removed.

Unfortunately, that conformance requirement is inadequate as an
interoperability assessment method. Because the validation occurs
after the removal of all foreign elements and attributes, the ODF
validation process itself is inadequate as an interoperability
conformance assessment methodology.

All major ODF implementing editors generate application-specific
foreign elements and attributes. The ODF validation procedure does not
test real world documents because the foreign elements and attributes
are stripped before validation. See e.g.,
<http://en.wikipedia.org/wiki/Validation>. ("Validation against an
incomplete or insufficient set of criteria can lead to a state of
'validated; where 'validated' does not confer the confidence that the
term intends. Thus validation of the validation criteria is an
important aspect that is often overlooked.")

A validation procedure that strips all application-specific extensions
to the formats in effect strips many interop breakpoints before the
document is validated and is therefore inadequate as an
interoperability assessment methodology. I.e., is not that fact the
very reason for this proposed TC?

I do not see that anything I raised is outside the preliminary
statement of this proposed TC's scope. Perhaps you might crank up from
only a general reaction to offer specific criticisms of my proposed
action plan? Is it not understandable? Do you see any technical
weakness in it? Do you have an alternative action plan to actually
achieve interop? I am not wedded to my action plan, but I am aware of
no other efficient roadmap that is technically feasible for actually
achieving it within the context of ODF implementations.

If you have your own concrete proposal for achieving interoperability,
I'm all ears. I want to see a well developed recipe for achieving
interoperability. You may well have a better plan. But I urge you to
disclose it if you do have one. We've discussed your plans for this TC
on the OpenDocument Fellowship list at some length. I have made no
substantial progress in understanding your goals for this TC  despite
our extended discussion. Are we here just to create the appearance
that someone is working on ODF implementation interoperability or to
actually achieve interop?

Moreover, what I have quoted from the TC formation email announcement
above is a "preliminary statement of scope for the TC whose formation
the list is intended to discuss."
Are you freezing the scope of this TC to the preliminary statement of
scope? My impression is that part of the purpose of this list is to
refine the preliminary statement of scope as needed. Am I wrong about

> But I'm all in favor of looking at what other groups have done, including
> the W3C, in the area of interoperability.  I sent out some links earlier to
> some of their practice papers and work in test case generation.

Good. To be more specific, are you in favor of looking at the W3C
Compound Document by Reference Framework as a candidate method of
working our way past the interop hurdles in the ODF standard? That's a
straightforward question requiring only a "yes" or "no" answer. But
please feel free to elaborate.

> Remember, ODF exists.  It is an OASIS Standard.  It is an ISO Standard.  It
> is supported and implemented by all the major players in this industry,
> including IBM, Google, Sun, Microsoft, Novell, Corel, as well as several
> important open source projects (and apologies to everyone I missed).  The
> question before us is how to improve interoperability in the world that
> exists, not to continually lament that world and pine for one that does not
> exist.

Are we not here to actually achieve interoperability? Do we not share
interoperability as a goal? Are we here for any purpose other than to
make interoperability happen? Are we not both pining for a world that
does not exist where office apps are interoperable? I am not here to
lament. I submitted a specific and affirmative action plan to actually
achieve interoperability. Are you saying it is impossible to achieve
interoperability? If so, why should anyone bother participating in
this proposed TC?

> I'm not here to fail.  I'm not here to tilt at windmills.  I'm here to apply
> my engineering know-how and work with other enthusiastic and talented
> volunteers to move ODF interoperability forward one small step at a time.

How? What is the IBM action plan? What is its methodology? What are
its milestones? If I am going to shell out the bucks to renew my OASIS
membership, I want to see a TC charter that is far less vague about
goals and milestones. We are in this interoperability mess precisely
because ODF 1.0 slid through JTC 1 without adhering to the Directives
requirement of "clearly and unambiguously specifying the conformity
requirements essential to achieve the interoperability." I chased you
many times around the mulberry bush before satisfying myself that IBM
had no plans to add such conformity requirements to ODF 1.2. You said:

"As for your question, you asked whether I will  "clearly and unambiguously
specify that conformance requirements essential to achieve the
interoperability" and will the standards-based interoperability between
*different* IT systems be "demonstrable," as required by JTC 1 Directives?

"To that I can say that we are rewriting the conformance clauses in ODF
1.2, per OASIS requirements.  I believe this also accords well with the
JTC1 requirements.  *But honestly, I also believe that what we have in ODF
1.0 also complies with JTC1 requirements.*"


But not well enough for implementers to achieve interoperability
without resorting to information outside the standard, eh? Otherwise,
what is the purpose of this proposed TC?

Rob, from the few clues you have offered since you proposed the first
ODF Interop Camp I have come to suspect that the difference in our
respective public positions on interoperability boil down to the
distinction between application-level interoperability and document
level interoperability. See
<http://www.universal-interop-council.org/glossary/term/2> and
respectively. You seem to push for the former while I push for the
latter. They are both technically sound approaches to achieve
interoperability. But in document format standards work, only
document-level interoperability work is lawful. Application-level
interoperability is lawful outside the standards context, except when
one player has a market power position, e.g., the court-mandated
disclosure of interop specifications in Commission v. Microsoft and
U.S. v. Microsoft..

From an economic standpoint, it is an issue of who controls
interoperability, of who controls the substitutability of products. At
the extremes, with application-level interoperability the vendor with
market power controls whose applications are permitted to interoperate
because the vendor is free to embrace, extend, subset, trash
conforming markup, whatever. With document-level interoperability,
everything needed for anyone to implement the standard and for their
implementation to interoperate is contained in the standard itself.
The control of interoperability passes from the vendors to the
standard. Interoperability is no longer a commodity that vendors can
sell or trade.

Dropping down to a more granular level in the context of
mega-specifications like ODF and OOXML, if lossless round-trip
interoperability cannot be achieved between less and more featureful
implementations, the effect of enabling only application-level
interoperability is to cement current market leaders in place by
denying round-trip interoperability to developers of less featureful
implementations. It is a "barrier to market entry" in economic and
antitrust terminology, an "unnecessary obstacle to international
trade" in the terminology of the Agreement on Technical Barriers to

It is a question of who controls the market; is it the entrenched big
vendors through under-specification of a standard or is it the
standard that specifies conformity requirements essential to achieve
the interoperability?

The W3C Compound Document by Reference Framework is designed to not
only allow but require the interoperability of less and more
featureful applications through profiles and mandatory compatibility
modes in the more featureful implementations. ("A conformant user
agent of a superset profile specification must process subset profile
content *as if it were* the superset profile content.") It is a
pro-competitive solution to a serious interoperability barrier.

More importantly, from what I can see it was specifically designed for
the relevant purpose (with IBM's full participation) by the
acknowledged leader in XML markup languages, the W3C. Am I wrong? Or
are we here to reinvent the W3C interop wheel for compound documents?

You said before in discussing the subject of specifying
interoperability conformity requirements in ODF itself that:

"I see a standard as providing a shared vocabulary for buyers and sellers
to express their requirements. Some users, like IDABC will seek
applications that do not extend ODF.  ODF should provide a way of
expressing the technical side of that requirement.  Other users will have
stricter requirements."

While I strongly disagree that such a view of an IT document format
standard is either lawful or in accord with the ODF TC's charter (a
"standard for office document processing and *interchange*"), my
question might be posed as to how this proposed TC intends to deliver
what IDABC and the other EU government bodies laid down as the
problems they expect industry to solve at the Open Document Exchange
Formats Workshop 2007 and the Advancing eGovernment Conference?
<http://ec.europa.eu/idabc/en/document/6474>, see particularly,
<http://ec.europa.eu/idabc/servlets/Doc?id=27956> ("Free the documents
from the software used to create them");
<http://ec.europa.eu/idabc/servlets/Doc?id=27865> ("interoperability
comes from data not from applications");
<http://ec.europa.eu/idabc/servlets/Doc?id=27862> ("Separation of
document format and application");
<http://ec.europa.eu/idabc/servlets/Doc?id=27866>  ("Problems with
vendor specific subsets/ super sets of standards [and] optional
elements within a standard").

Will this proposed TC deliver what IDABC and the other government
bodies require? I offered a concrete action plan for doing so. What is
IBM's action plan for fulfilling the same market requirements using
what you term as the ODF "shared vocabulary" for buyers and sellers to
specify their requirements? Or is that there no IBM action plan for
fulfilling such market requirements or that IBM has a plan but you are
not authorized to reveal it?

I am not the only one pining for a world that does not exist. Rob, I
was a participant when the budding computer industry first successfuly
commercialized electronically automated word processing in the daily
newspaper industry by embracing and extending the 6-bit Teletypesetter
"TTS" standard. I well remember when "markup" was a de facto standard
of handwritten symbols used to assign formatting instructions for
folks who set type in molten lead. And I've been watching closely and
waiting for an interop solution ever since.

By my count, the big vendors have had about 40 years to demonstrate
their ability to create a word processing format standard designed for
interoperability of competing implementations. That is how long the
big vendors have kept us locked into their own word processing
products. In all that time, I've acquired a bit of cynicism.

From my experience, the big vendors have had no solution to the office
productivity software interop problem; I am now firmly convinced that
they *are* the interop problem. It is the policies of the big vendors
that pose the real interop barrier. The technical barriers pale in
comparison. And I see no substantial improvement in the fact that
multiple vendors distribute their own clones of OpenOffice.org,
particularly when a single vendor holds the key for that code base and
is also contractually bound to stand aside if and when Microsoft
decides to unleash its patents on OpenOffice.org.

Incremental improvement in interoperability is not an action plan,
Rob; it is an excuse for not having one. You are a software architect;
show me your blueprints, please. Please show me that this proposed TC
will be any different from the ODF TC when it comes to
interoperability. Please convince me that the agenda this time around
really is the achievement of interoperability, something far less
nebulous than "incremental improvement." If you do that, you will have
my support.

Brushing aside a proposed action plan to achieve interoperability
without offering IBM's own action plan is not getting off to a good
start. If IBM has a better plan, let's hear it, Rob. How does IBM
propose to get us from the present mess to an ecosystem of competing
but interoperable applications? I've offered one road map. What is
IBM's? The ODEF Workshop identified one of its "expectations on
software vendors" as "transparency of future plans of software
vendors." <http://ec.europa.eu/idabc/servlets/Doc?id=27865>.

I think that this would be a good time for IBM to begin fulfilling
that expectation.  IBM either has an action plan for this proposed TC
to achieve the interoperability of ODF implementations or it does not.
Brushing aside a concrete proposal with the excuse of "incremental
improvement" does not convince me that IBM has any serious intention
of fulfilling the interoperability market requirement within my
remaining lifetime. Fifty years of vendor lock-in has been 50 years
too much for me.

What I am looking for here, Rob, is an IBM commitment to making ODF
interoperability actually happen with a concrete plan for achievement
that I can look at before I decide whether to plunge myself back into
committee work. I remain fully sensitive to the fact that you likely
do not have the power to set IBM policy on many relevant matters, so
none of this is aimed at you personally.

At the same time, still wearing the scars from having banged my head
repeatedly against the ODF TC's interop stone wall, it's going to take
a strong signal that IBM and Sun policy has changed in regard to ODF
interoperability before I would advise anyone to take this proposed TC
seriously, particularly when the ODF TC remains in a position to undo
any interop profile work done on this TC by changing ODF conformance
requirements itself..

Which reminds, why is a separate TC necessary? Wouldn't it make more
sense to amend the charter for the ODF TC itself to do the work of
this proposed TC?

>  This is the price of success.  If ODF had failed, then no one would care
> about interoperability.  If ODF had few implementations or little vendor
> support, then none of this would matter.  But with recent announcements in
> the industry, ODF is positioned now to be the most-widely deployed document
> format around, supported by every major word processor, spreadsheet and
> presentation graphics package on every platform.  The success in adoption of
> ODF, around the world, coupled with the strong user demand and subsequent
> vendor support makes interoperability work more important now than ever.
>  We're only having this discussion because ODF won.

In my humble opinion, it is far too early to pronounce victory,
particularly when ODF and OOXML remain standards in name only. Both
are too amorphous to be used for document interchange work. I.e., if
you want OOXML interop, everyone uses the same version of MS Office.
If you want ODF interop, everyone uses the same version of OOo or
clone thereof. For the software users of the world, it's still a
choice between whose code base you prefer to be locked into. According
to my tea leaves, the winner will be the first specification that
demonstrates document-level interoperability among competing
information technology systems. As was said at the ODEF Workshop:

"There is no functioning market."

Best personal regards,


Universal Interoperability Council

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]