Re: [oiic-formation-discuss] PROPOSAL -- Name change for proposed TC

[marbux <marbux@gmail.com>]

On Wed, Jun 18, 2008 at 3:35 PM, jose lorenzo <hozelda@yahoo.com> wrote:
> --- On Wed, 6/18/08, marbux <marbux@gmail.com> wrote:

> I like the existing name. I also like this one as more marketable, but is that necessary?

It is not necessary in the sense that it is required. I am more
concerned that the relationship of this proposed TC to the
requirements established by E.U. government and any relevant
concessions or agreements among the big vendors as a result of the DG
Competition investigation be disclosed and reviewed by the
participants in this TC formation meeting. There is a hidden big
vendor agenda as to ODF interop that needs to be disclosed for any of
us to intelligently evaluate the merits and demerits of big vendor
actions and positions at this meeting.

I am very concerned that the big vendors not be allowed to cut deals
in a back room and then impose their deals on us through block voting.
Agreements to vote in a block to achieve anti-competitive goals in a
standards development organization is an extremely grave violation of
anitrust law both in the U.S. and in the European Union. That is why
DG Competition has been investigating allegations that Microsoft
arranged for block voting to rig national standardization body votes
on adoption of OOXML in a number of national standardization bodies
around the globe. EC DG Competition Commissioner Neelie Kroes
discussed the illegality of such behavior last week in a short speech
that I linked from my first post in this thread.

The U.S. Supreme Court spoke directly to that issue in the case of
Allied Tube & Conduit v. Indian Head, Inc., 486 U.S. 492 (1988),
<http://laws.findlaw.com/us/486/492.html> ("What petitioner may not do
(without exposing itself to possible antitrust liability for direct
injuries) is bias the process by, as in this case, stacking the
private standard-setting body with decisionmakers sharing their
economic interest in restraining competition) (jury award of treble
damages upheld for violation of the Sherman Act's section 1
prohibition against conspiracies in restraint of trade). Violations of
that section are also crimes punishable by fine not exceeding
$100,000,000 if a corporation, or, if any other person, $1,000,000, or
by imprisonment not exceeding 10 years, or by both said punishments,
in the discretion of the court."
<http://www.law.cornell.edu/uscode/html/uscode15/usc_sec_15_00000001----000-.html>.

In the E.U., there are no criminal penalties that I am aware of, but
DG Competition is allowed to fine companies that violate Article 81 of
the treaty establishing the European Union in the standards body
setting with fines up to 5 percent of a company's annual profits.

As the Indian Head Court's decision makes plain, decisions reached
within the setting of a voluntary standards organization are to be
based *only* on technical merit; backroom deals for anticompetitive
ends are prohibited.

I care mightily whether the negotiations among the big vendors about
the future of ODF take place in private or in public. By law, such
negotiations must take place in a standards organization and be
conducted in public, with any participant having the *right* to take
part in the negotiation of a standard.

I am here to insist that interoperability be enabled not only for the
big vendors but also for the developers of smaller apps. If that does
not happen, the work of the proposed TC is a conspiracy in restraint
of trade in the U.S. and a violation of Article 81 in the E.U. This
notion of writing standards that enable interoperability only for the
big vendors is also a straightforward violation of the international
Agreement on Technical Barriers to Trade, which prohibits the
preparation, adoption, or implementation of standards with a view to
or with the effect of creating *unnecessary* obstacles to
international trade.

And interoperability is not a feature of an information technology
standard. It is the fundamental legal requirement. Only
interoperability allows competitors to complete. ODF and OOXML are
both unlawful precisely because they do not *require* round-trip
interoperability of implementations. IT standards that do not require
interoperability simply hand control of the standard to the vendor
with the largest market share. It standards that do not *require*
interoperability violate competition law globally.

I have developed a solid and unimpeachable record that IBM has been
manipulating this meeting to thwart interoperability, particularly
when considered in light of evidence of prior related misconduct that
I have accumulated over the last four years of full-time investigation
and involvement.

The fact that the real negotiation between the big vendors would be
formalized by the language of ODF v. 1.2 has been public knowledge
since Microsoft's announcement that it would provide native ODF 1.1
support and would join the ODF TC to work on ODF 1.2. Microsoft has
now joined the ODF TC yet has no presence in this meeting that I have
seen.

When Rob Weir began talking up the formation of this TC on the
OpenDocument Fellowship mailing list, I immediately realized something
was amiss. It is impossible as a technical matter to profile the
existing OpenDocument standard in an interoperable, application
neutral way. ODF is not designed for interoperability and is full to
the brim with application dependencies. The work to convert the OOo
XML formats to application-neutral formats has yet to begin. Any
serious effort to profile the ODF standard in an application-neutral
matter requires that the standard itself be rewritten to remove the
interoperability barriers and application dependencies. It is not a
task this proposed TC could accomplish without breaking compatibility
with ODF itself.

There are similar issues of fraud involved in the hype about this TC
developing conformance testing tools for ODF. *Every* mandatory
conformance requirement of the ODF standard relating to the markup is
already fully testable by validation against the schema after all
foreign elements and attributes. Non-mandatory normative requirements
are not a barrier to claiming conformance. The ODF standard is such
sorry state that a Zip file with the XML 1.0 and Office XML name space
headers in it and all other content marked up with OOXML is still a
conformant ODF document.

IBM knows this. IBM knows that the only way to achieve
interoperability using ODF is for everyone exchanging documents to use
the same application. That is precisely why IBM chose to clone the
code base of the most featureful implementation, OOo, for its own
proprietary software products. The application dependencies in ODF
prevent anyone from feasibly developing an application from scratch
that can round-trip documents with OOo.

The only way ODF could be profiled in an application neutral and
interoperable manner by this proposed TC would be to determine at the
outset that compatibility with ODF must be broken and a new standard
created using ODF as a very rough guide.

IBM knows all ot this. My task here has been to offer IBM an
opportunity to prove that it has turned a corner on its
anti-ODF-interop policy. IBM has declined to act on that opportunity.
I now have sufficient evidence to prove that IBM has no intention to
allow this proposed TC to deliver profiles that would enable
interoperability different implementations of the same profile. This
meeting is a fraud, an appeal to ignorance.

>> 3. If this TC's profiles are faithful to the goal of
>> interoperability,
>> those profiles will eventually displace the work of the ODF
>> TC in the
>> market and become the new standard. At such time, those
>> profiles will
>> need a name to brand them separately from "ODF."
>> The name I propose
>> and its acronym ODEF fulfills that requirement.
>
> Hold horses.
>
> Usurping the ODF TC while using a marketable name that sounds an awfully lot like ODF smells very fishy.

I can't respond to "fishy." Please be more specific.


> As for competing with the ODF TC, I look forward to building intraODF profiles first and in a way that is compat with the current ODF spec structure. Later, ODF would likely be rewritten. It might explain the outer shell and concepts necessary, deferring the actual definitions to profile modules. The umbrella ODF std text body may include the core profile(s) inline.

You missed a few key facts. There is no way to create profiles that
are compatible with the current ODF spec structure and still be
interoperable among different IT systems. Your desire for profiles
compatible with the existing spec cannot possibily be fulfilled in an
interoperable way.  Another fact that you missed is that the real
interop work is not happening in this proposed TC. It's being
negotiated behind closed doors and will be formalized as ODF 1.2 by
the ODF TC. Any attempt to profile the existing ODF spec would be an
exercise in futility.

Microsoft cannot support ODF v. 1.2 without very substantial
modification of the existing ODF v. 1.2 draft, because of the
application dependencies in ODF. ODF v. 1.2 will be very different
from earlier versions if it is to be implemented by Microsoft in a
manner that  enables round trip interop between the OOo code base and
the Office code base. By the time profiles of the existing ODF spec
might be created, even were they usable only by the OOo code base, all
earlier versions of ODF will be obsoleted and incompatible with ODF
1.2. Either that, or ODF 1.2 will no more enable high-fidelity round
trip interoperability than the earlier versions of ODF.

Neither ODF nor OOXML were designed for round-trip interop between
different IT systems. There is no real standard in either standard. I
was hoodwinked too when I wrote my first article that triggered the
global attention on the ODF vs. Microsoft XML file format war.
<http://www.groklaw.net/article.php?story=20050330133833843>. I fell
for the baloney that ODF was designed for interoperability. (By the
way, if you want to read article later, you might save a copy quickly.
Either the Groklaw search engine is having problems or Ms. Jones has
begun removing the many articles I wrote for Groklaw before I couldn't
take working with her anymore. I hope it's the former because
destruction of evidence is a big no-no once a party becomes aware that
litigation is foreseeable.)

> Without proof (ie, examples with args), I don't see that ODF can't be fixed so as to retain much of its current organization were that desirable.
> I could use examples here. It may take a while for me (to get motivated) to comb ODF properly.
>

I am sorry that I don't have time right now to fill you in on many
years of personal study of the  interop barriers in ODF and OOXML and
the barriers to interoperability between the OOo code base and the
Microsoft code base.  If you contact me by private email, I could
provide you with a working draft now standing at some 130 pages that
compares the interop features and failings of ISO:IEC 26300, Ecma 376,
and W3C CDRF plus the WICD profiles. I stress that it is a rough
working draft, very incomplete, and I am aware of errors in it that I
have not had time to correct. However, my recollection is that those
uncorrected errors I spotted were of a fairly minor nature. I decided
to put that project on hold once it was clear that Ecma 376 would
undergo very substantial revision at JTC 1. My current guess is that
the completed work will be somewhere in the neighborhood of 500 pages.

If more people want to take the time to read 130 pages, I could
probably find time during the next 24 hours or so to put it up for
downloading from the web site in my signature, with a page explaining
why it is being posted in working draft state and containing caveats
about its reliability.

I'm afraid that is the best I could do to jump start your familiarity
with issues of the type you ask about in the time I have available
right now. I really must focus more on talking to the folk who already
understand the technical issues.

> I don't yet see this. Interop with other standards can always occur according the the object/embed reference framework defined in CDRF. To intermix XML elements from different stds is simply a different definition of interop and is more difficult to achieve. ODF has been accepted as is. It is implementable.

In one of my posts, I explained that I am not personally interested in
the CDRF methodology for creating compound document formats. ODF
already is a set of compound document formats. I raised the ability to
combine ODF with other formats only because some on the list had
expressed interest in doing so, and to point out another opportunity
available if CDRF is specified as the interop framework for the ODF
profile work.

> More study is needed (by me), and I am not sure this TC will come to the conclusion to move along the lines of CDRF/WICD aggressively to address high integration with other XML protocols. Interop is achievable at a higher level in the near future without diving into CDRF defined profile integration to any depth.

See my last paragraph. Also, my only proposal in regard to the WICD
profiles was that the proposed TC consider developing profiles that
correspond to the feature sets of the WICD profiles for transformation
purposes and to align ODF for the transition of ODF into the emerging
convergence of desktop, server, mobile device, and Web applications.
Maintaining compatibility with W3C's compound document formats and
interop framework for them could conceivably affect the date upon
which ODF becomes obsolete by many years. E.g., one of the profiles
suggested for the proposed TC is an ODF profile for mobile devices.
W3C is well into the implementation stage of such a profile for its
compound document formats. Matching the feature set of the ODF profile
with the feature set of the W3C profile would enable transformations
between them. That is not a trivial interoperability feature for the
proposed TC to offer the market.

>
> My main concern, fwiw, is to keep FOSS, specifically GPL applications that can introduce serious competition into the current market, healthy and competitive. ODF, as is, seems a fitting path for this. The ultimate concern (for this TC.. according to my current world view) should be to fortify a standard that can re-establish balance in the marketplace.

I share the goal but not the methodology. Microsoft claims to hold 45
patents reading on OOo and to the extent that implementation of ODF
infringes those patents, they need to be worked around in the profile
work. As mentioned and linked earlier, Sun has an agreement with
Microsoft that gives StarOffice licensees and Sun patent protection,
but none to OOo. Sun also agreed not to interfere if Microsoft sued
any OOo licensee for patent infringement. Sun has exclusive control of
the OOo codebase and it is the company all other implementors' and
users' licenses flow from. Short story here: Sun walked FOSS out to
the end of the Microsoft gangplank and traded cash for Sun's sword to
protect anyone who uses the OOo code base. Because the specific
patents have not been identified, I do not know the extent to which
implementation of ODF is subject to Microsoft patent infringement
claims.

Many have been misled into believing that Microsoft is the only big
software company that misbehaves and that Microsoft is the only big
software houses creating legal and technical interop barriers.  There
are foxes in the ODF hen house too. Much disinformation about ODF has
been disseminated. There are few willing to speak who comprehend just
how thoroughly Sun and IBM have betrayed FOSS in regard to ODF.

As to the major structure of ODF, there are issues even at the
namespace level. For example, three W3C standards are incorrectly
implemented in ODF using unique OASIS namespaces, SMIL, SVG, and XSL
FO. This was to avoid the need to go to W3C to have profiles developed
for the desired feature sets and in the case of SVG also to add 3-D
features. SVG was split into two namespaces, with a separate namespace
for the SVG features that acquired a third dimension. The latter
namespace includes much of the markup for the SVG features, with at
least one extended with an attribute that does not exist in SVG. These
are all interop issues in terms of transformations to other formats.

Ultra-high fidelity transformations are a fundamental market
requirement in automated business processes, where applications
reading and writing to different formats must be integrated, as in a
SOA, so these structural issues are in urgent need of repair. They are
a barrier to ODF integration in the largest enterprises, where
processes are already bound to Microsoft software.

The largest barrier to FOSS ODF app entry into the enterprise market
is the ODF incompatibilities with MS Office. Most of the CIOs we have
talked to simply laugh when the idea of ripping out Microsoft Office
and replacing it with OOo is raised. They are locked in. If there is
no FOSS method for achieving high-fidelity round trip conversions
between Microsoft formats and ODF formats, FOSS is largely locked out
of the enterprise market.

We reverse engineered the Word and Excel native file support APIs and
had ultra-high fidelity plug-ins for Office that converted between the
Microsoft binary formats and ODF plus a very few extensions. We also
had plans to migrate the decoding toan Infoset API that could be used
by other apps to do the conversions. Both were going to be FOSS tools.

But IBM and Sun blocked the extensions we needed from being adopted as
part of ODF 1.2, twice, once as to elements and attributes and once as
to the only other way we could come up with to do the conversions, by
using the RDF metadata support that is in the draft ODF 1.2 spec. What
we generated with Excel and Word was conformant ODF (only because ODF
illegally bestows conformant status on app-specific extensions).
Because we had no interest making Microsoft the market leading ODF
implementation if its ODF was incompatible with OOo, we withheld our
software from the market and only released our proof of concept
implementation of the Word plug-in.

Our plug-ins had no signficant remaining issues doing the conversions
within Word and Excel. Our barrier was OOo coding  (controlled by Sun)
and the ODF TC (controlled by Sun and IBM). I do not shoot from the
hip when I say that ODF 1.2 will have to change radically for OOo and
MS Office to interoperate using ODF as the medium. OOo will require
far more reprogramming than Word and Excel.

And ODF 1.2 will have to forbid a good part of the way OOo is
programmed to use ODF as the exchange medium. However, Sun appears to
be throwing its conversion bucks into developing OOXML support for
StarOffice/OOo. Given past conduct, I think the odds are very low that
Sun will allow OOo to be reprogrammed to establish OOo-MS Office
interop using ODF as the medium, at least until the competition
regulators awaken to the fact that Microsoft is not the only big
vendor in the market that has been misbehaving.

I would not want to venture very far into predicting the extent to
which apps will be reprogrammed  as opposed to the extent to which ODF
will require structural changes to accommodate using ODF as the
exchange medium between MS Office and OOo in a round-trip
interoperable way. We do know beyond doubt that OOo's programming is
by far the largest barrier. And I do not know whether achieving
high-fidelity interop with OOo is even on the agenda of the back room
dealing.

Microsoft claims to have 45 patents it could assert as grounds not to
be concerned with Office <> OOo interop. And I know beyond doubt that
Sun, Microsoft, and IBM all have an aversion to specifying conformance
requirements in their respective XML file format standards that are
essential to achieve interoperability. All three companies love
*application-level interoperability* application instead. See
definition of emphasized term at
<http://www.universal-interop-council.org/glossary/term/2>. So the
potential for backroom dealing to achieve only application-level
interop rather than standards work is enormous. Only one element of my
proof that IBM is playing games with us here is Rob's opposition to my
proposed name change and its aligment with the market requirements
established by E.U. government is that one ot those requirements is
document-level interop as opposed to application-level interop.  IBM
has no interest in making interop available to all. The evidence says
that IBM's goal is a private deal with Sun and Microsoft. The only
evidence cutting the other way is mere mouthing of the word
interopability without a single step committed to by IBM on the ODF
interop walk.

>> There is no way to avoid reprogramming of existing
>> implementations if
>> the goals of interoperability and application neutrality
>> are to be
>> fulfilled by this TC's work.  If this TC's work is
>> to succeed, the
>> application dependencies must be removed in the developed
>> profiles and
>> an application-neutral interoperability framework must be
>> fully
>> specified. The goals of interoperability and application
>> neutrality
>> necessitate a fork from the ODF standard that requries its
>> own name.
>
> I am waiting for the examples that show that ODF cannot be implemented reasonably by an applications maker starting today. Sure, some existing applications will need to be changed. That goes with the territory. It would be especially true if those applications had never established a way to map to a fairly neutral format. I suspect most proprietary formats never really intended for interchange would find this task expensive in the short-term.

ODF is a blank check for whatever a developer wishes to do so long as
they do it in their own unique namespace and include the XML 1.0 and
Office XML namespaces in zip file. See sections 1.2, 1.3, and 1.5. in
any version of ODF other than OASIS ODF 1.0, which incorporated the
modal definition of "may" with its mandatory interoperability
requirements from RFC 2119. all of those requirements disappeared at
JTC 1 when the JTC 1 Editor for ODF, Patrick Durusau, toggled them off
by substituting ISO/IEC Guidlines definitions for RFC 2119 definitions
in ODF section 1.2.

Other than in the OASIS 1.0 version, everything but the minimal
requirements I mentioned above is discretionary, including the "may"
in section 1.5 that allows application-specific extensions. Please
realize that under the ISO/IEC definitions, "may" has its common and
ordinary meaning of permission. Under the RFC 2119 definition as
applied to the foreign element and attributes two MUST
interoperability requirements are there including that an
implementation that exercises the discretion to create extensions must
maintain the ability to correctly read and write to unextended
formats. OOo 2.x writes files using some 150 app-specific extensions.

Two developers could agree on how they will exercise the discretion to
achieve interoperability between their own apps. I.e., developers can
agree on an ODF profile. What one may not do is to achieve round-trip
interoperability with any apps whose developers do not support the
same profile. However, it would be very difficult for an app of any
complexity to create a profile without using the discretion granted by
the ODF spec to use app-specific extensions. See e.g.,, this extract
from the OOo source code at lines 169-211.
<http://lxr.go-oo.org/source/sw/sw/source/ui/uno/SwXDocumentSettings.cxx>.
Those are extensions to ODF that OOo writes for compatibility with the
pre-ODF version of the StarOffice XML formats. Now try to decode the
functionality of the extensions. ... Not done yet? Are you getting a
clue yet about just how messed up ODF is?

Now try the last paragraph of ODF section 1.5 where it says that there
are no rules as to what elements and attributes must be supported.
Skip the second half of that sentence because it says one "should" not
use foreign elements and attributes for features defined by the
specification. But "should" does not create a conformance requirement.
It only recommends. Those who ignore "should" and use foreign elements
and attributes for features defined by the spec are still conformant.
If one throws the XML namespaces made mandatory by ODF section 1.3
into a zip file and writes the rest of the document in OOXML, one has
a conformant ODF document.

Now take a look at the part of section 1.5 that talks about
preservation of foreign elements and attributes. Do you think that
just maybe they meant something else when "may" was defined by RFC
2119? Sun exercised the discretion provided by the switch to ISO/IEC
Guidelines definition of "may" to program OOo to destroy all foreign
elements and attributes other than its own, and paragraphs and text
spans. How would you tackle that interop barrier, now implemented in
not only OOo but all of its clones? How would you round-trip documents
with the code base that monopolizes the ODF app market?

Are you getting at all nervous yet about FOSS reliance on ODF yet,
with Sun controlling the OOo code base and Microsoft claiming to hold
45 patents that read on that code base?

ODF is *massively* underspecified. E.g., KDE has been trying since
2005 to get Sun to specify the document settings that OOo generates
and get that spec into the ODF 1.2 standard. The KDE proposal was
accepted as a TC work item twice, but somehow fell off the agenda
maintained by Sun both times. I issued some public embarrassment after
IBM took over the TC in the form of a history of the proposal's
repeated mysterious disappearances from the agenda without a TC vote
to drop it, complete with links to the relevant postings to the TC
mailing list archives.

IBM responded to the public embarrassment and hat work is now
happening, with the app-specific document settings and default values
for them used by all of the major implementations being harmonized,
hopefully for specification in ODF 1.2 I have yet to see any written
indication that this is the goal of the harmonization work; the way
the ODF TC operates, it would be as reasonable to suspect that the
information will not make its way into the standard. This event
confirmed the wisdom of our decision to abandon work on the TC itself
and to apply pressure on the TC through publicity. None of my
proposals were ever adopted by the TC and whenever an interoperability
proposal was put forth by anyone while I was on the TC, it was either
ignored or voted down by Sun and IBM.

But short story, if you wish to create a profile from an existing
version of the ODF spec, even document settings are unspecified and
foreign elements and attributes must be used for the purpose. You hope
to create a silk purse from a sow's ear, my friend. There *is* no
standard in the ODF standard. The only difference between ODF and
OOXML of significance is the patent restrictions on OOXML. This is not
to say that ODF is beyond salvage. But it will require bringing the
big vendors to heel to do it. That is do-able. But it will require
either massive public pressure or lawyers to make it happen.

> Keep in mind that OO.o implements ODF today and is open source. I also haven't seen any specific and good args that ODF cannot be implemented by other apps. [Many others paying attention have also likely not read the ODF spec except maybe partially.] ODF relies on existing W3C and other standards. This is a Good Thing. Contrast with OOXML (in terms of quantity).
>
But OOo is encumbered by Microsoft patent claims and Sun has
contracted with Microsoft not to interfere if and when Microsoft
lowers its cannon at OOo with a 45-patent salute. Of course you may
implement ODF in other apps. You simply cannot round-trip interoperate
with any other developers' apps who do not support the same profile
and you will have great difficulty in designing a profile that does
not require extensions to the ODF specification if your apps are very
featureful.

Microsoft and Sun maneuvered FOSS out onto the end of limb with OOo
and ODF. If FOSS wishes to fortify ODF, FOSS must take control of ODF
away from the big vendors that have abused it.

> FWIW, the W3C is subject to vendor control like any other org.

Agreed. But W3C does a far better job at producing vendor neutral work
than OASIS and Ecma.  W3C, for example, is many more miles concerned
about interoperability than OASIS and Ecma. But the vendor power at
OASIS lies with the browser developers and their ability not to
support W3C work, like the WICD profiles. The Mozilla insistence on
HTML 5 instead is playing right into Microsoft's hands. E.g., neither
HTML 5 nor CSS even define elements for footnotes and footnote calls
and processing of tables of contents requires resort to the HTML 5
heading tags that produce huge and tiny headings to achieve
outline-style nested and ordered lists unless a site's stylesheet is
set to process them otherwise.

Office 2.0 on the Web is evolving just like the desktop office
productivity software industry evolved. No standard format for
document exchange among apps on the desktop, servers, mobile devices,
and the Web. That  is the hole in the open standards market that W3C
is trying to fill with CDRF and the WICD profiles. But they are being
fettered by Microsoft's refusal to support the WICD profiles and loud
voices of the browser developers including Microsoft pushing tag soup
HTML and CSS support rather than profiled content.

Meanwhile, OOXML bridges from Office to Sharepoint to Dot.Net to XAML
and beyond with the Web Services standards identified in the Microsoft
Open Specification Promise, an interoperable stack stretching from
mobile devices to the Web, with patent encumbered technology every
step of the way. <http://www.microsoft.com/interop/osp/default.mspx>.

FOSS clings to a Microsoft patent-encumbered 1995-style office suite
and non-interoperable set of formats for it while giving Microsoft a
13-year head on embracing and extending the Web. The big FOSS mistake
was trusting *any* big vendor. The vendor lock-in that used to be
protected by trade secret binary formats maintained as moving interop
targets is now protected by patents, under-specification of "open"
standards, and moving interop targets. Did you realize that there are
*no* featureful implementations of ISO/IEC:26300 OpenDocument, the
international standard? *All* of the featureful ODF implementations
now write to somewhere between ODF 1.1 and 1.2, plus app-specific
extensions. But they can't write to ISO/IEC 26300.

Are standards meaningless? Are we so enthralled in feature wars that
interoperability just gets left on the shelf?

Microsoft has a 13-year head start on FOSS document-level
interoperability. How much more lead should we give them before we
begin worrying about interop?

> Don't confuse vendor interoperability of ODF with interoperability
> with all existing W3C standards. ODF already reuses W3C to an
> extent while adding some document specific semantics.

I have no such confusion. On the other hand, I am not oblivious to the
 market requirement for transformability of XML formats at the
enterprise level. If FOSS wishes ODF to participate in
enterprise-level automated business processes, ultra-high fidelity
transformations are a threshold requirement of eligibility. In an
automated business process that parses documents, extracts
information, transforms it to another format, then serializes content
to assemble a new document and render it, there is no opportunity for
manual inspection for conversion artifacts. A XML-based compound
document format specification must provide high confidence in
ultra-high fidelity in transformations to be eligible in that market.

Neither am I oblivious to the fact that ODF is designed for a 1995
style desktop office suite and is non-interoperable among
implementations unless they share a common code base that is
encumbered by Microsoft patents or privately negotiate profiles that
include extensions to the standard.

Moreover, I likewise am not oblivious to the fact that ODF is not
participating in an interoperable fashion in the grand  convergence of
desktop, server, mobile device, and Web apps that is now well under
way. ODF either joins that convergence or it will be quickly
obsoleted. We deal here with a non-interoperable document format
standard for an application type designed in the days when the lowest
common denominator was the stand-alone PC, the sneaker net days.

Bill Gates comprehended in 1995 that an era of ubiquitous networking
was dawning. Ever since, Microsoft has concurrently throwing
roadblocks in the way of competitors trying to obtain first mover
advantage in the connected world whilst constructing and executing on
a strategy to dominate the connected software world. FOSS, meanwhile,
falls into the trap of one of Microsoft's roadblocks called
OpenOffice.org and fiercely defends a set of formats controlled by a
technical committee still locked to the vision of a 1995-style office
suite built by a German company that tried to build a better Microsoft
Office than Microsoft did. There is no vision of the connected world
on the ODF TC.

FOSS, not being organized in a top-down chain of command like
Microsoft, has by and large not bothered to perceive even the outline
of the Microsoft strategy for dominating the connected world. Most
FOSS developers and users have had only glimpses of bits and pieces.
Interop is fundamental in a connected world. One may not build a Free
Information Infrastructure without interoperability. An app may either
converse with the global network or it may die from obsolescence. So
too with open standards.

My message is that ODF is badly broken and 13 years behind Microsoft.
Either fix ODF or lose it.

On the W3C standards you mention, three are implemented incorrectly in
ODF, producing interoperabiity barriers as explained above. Those
three standards were hijacked from W3C, not borrowed. I am pleased to
see that you caught that ODF did an embrace and extend on W3C
standards. The problem is that the ODF TC never bothered to go to W3C
to get its extensions into the relevevant W3C specs and to get W3C
profiles developed for the features of W3C standards used in ODF.

The result is lossy transformations and an inability to do round-trip
transformations with ODF at either end with confidence there will be
no conversion artifacts. ODF is thereby isolated from the connected
world.

But the issue I raised through my proposal to change the TC's name is
whether there is any commitment to fulfilling the interoperability
requirements laid down by E.U. governments for the big vendors that
control ODF and OOXML. Rob Weir's initial response was to duck the
meat of my proposal and to make lame excuses for not aligning this
TC's name and charter with the market requirements the E.U.
governments established. I now have full confidence that this proposed
TC's formation notice is a fraud. This formation proposal is a
distraction, not a serious effort to actually achieve
interoperability.

Please understand that as far as I know there is only one remaining
advocate for interoperability on the ODF TC, Novell's representative,
who was formerly the OpenDocument Foundation's CTO. Gary Edwards and I
gave up on working through the TC last year and dissolved the
Foundation. We have had far more influence on the standard working
outside the TC than we ever achieved working in it, despite IBM's best
efforts to discredit us.

> Focusing on inter-vendor interop for *ODF* is a different problem than what you are talking about above with CDRF, not that greater interop with other standards isn't a good idea to the extent that can be reasonably done without damaging the potential to introduce competition to a single vendor dominated market.

I agree to the extent that the ODF app <> ODF app interop barrier must
be removed before one could even begin work on transformation issues.
We have a sow's ear to work with; what will we make of it?

> This TC should work closely with the ODF TC. I would think.

I now think not. Only the ODF TC can repair ODF and my suggestion that
this TC write a new standard roughly based on ODF has been soundly
rejected by IBM. This proposed TC is not about interop. It is about
distracting public attention from what is going on behind closed
doors.

> A rose by any other name... I think we should focus on content more than on developing a marketable name that might piggy-back on ODF while being incompatible with it.

I now could care less about the name of the proposed TC. I have my
evidence that IBM has no intention of fulfilling the E.U.'s ODEF
requirements on this proposed TC. IBM ran from the suggestion rather
than addressing the issue. Coupled with the other IBM statements on
this formation list and other evidence accumulated over the years, I
am personally satisified that I can prove that this is just another
IBM smoke screen for delaying the interoperability  of ODF
implementations, no better than Bob Sutor's propaganda that ODF is an
open standard that already enables interoperability.

IBM remains as comfortable as ever with the status quo on the ODF TC.
IBM has not turned the corner from its anti-ODF interop policy. IBM
talks the ODF interop talk; it runs from the first step on the ODF
interop walk.

> Speaking for myself, I am all for hearing out the arguments in favor of any path.

If IBM does not stop waffling and come out squarely for sticking CDRF
in the charter, we may all as well stop wasting precious bits on this
list. It is the only workplan on the table that is actually designed
to achieve interop. *All* of the big vendors participating in the
office file format war talk the interop talk. This industry has had
four decades to walk that interop walk when it comes to word
processing. I was there and involved when industry -- led by IBM --
embraced and  extended the Teletypesetter telegraphy standard to first
successfully commercialize word procesing technology, in the North
American daily newspaper. I was a newspaper typographer for over 20
years before I went to law school and I began that work before the
embrace and extend.

I've been watching this farce go on for over 40 years. Ain't nothing
new here folks, might as well move on.

> I am hearing you. Like I said, I am open to discussion and backed arguments that I think will help keep FOSS alive and healthy. Ultimately, FOSS is more valuable to users than any "open standard" would be because you can always interoperate with open source since you can see the source and development is ultimately open to anyone (even if through a fork when the project lead are unresponsive).

I think it's time for FOSS to develop its own standards, with the
800-pound gorillas kept in a cage.  At worst, they try to kill FOSS,
like Microsoft. At best, they seek to control FOSS, like IBM. They do
not embrace FOSS principles. They're still into vendor lock-in games.

You might consider the fact that for all its claimed FOSSiness, IBM's
clone of the OOo code base is proprietary and distributed only in
binary format. That worked with the OOo 1.4x code base, which was dual
licensed under LGPLv2 and the BSD-like SISL. But after IBM showed up
on the ODF TC the day before the ballot closed on OASIS ODF 1.0, Sun
closed the IBM door on the OOo 2.x codebase by issuing it only under
the LGPLv2 license.

I've got a stack of circumstantial evidence a mile high that Sun cut a
deal late last summer for IBM to use the OOo 2.x+ codebase in IBM's
proprietary ODF apps. E.g., IBM committed 70 develelopers to the OOo
project and assumed the leadership of the ODF TC where it now has by
far more members than Sun. Does that make any business sense to you if
IBM did not acq

>
>>
>> Why is this TC not a waste of everyone's time? I want
>> full disclosure
>> of the big vendors' interop agenda for ODF. I am not
>> interested in
>> being used as a pawn by the big vendors to distract public
>> attention
>> from the real negotiation.  Disclose the real interop
>> agenda or stop
>> wasting people's valuable time.
>>
>> As was said by E.U. DG Competition Commissioner Neelie
>> Kroes last week
>> when she laid out the guidelines for the IBM-Sun-Microsoft
>> negotiation
>> of interoperability between their applications:
>>
>> "... standardisation agreements should be based on the
>> merits of the
>> technologies involved. Allowing companies to sit around a
>> table and
>> agree technical developments for their industry is not
>> something that
>> the competition rules would usually allow. So when it is
>> allowed we
>> have to look carefully at how it is done."
>> <http://europa.eu/rapid/pressReleasesAction.do?reference=SPEECH/08/317&format=HTML&aged=0&language=EN&guiLanguage=en>.
>>
>> I also wish to "look carefully at how it is
>> done." Which TC should I
>> be watching, this one or the ODF TC? I have no interest in
>> this
>> proposed TC if the real interop decisions are going to be
>> made on the
>> ODF TC.  Disclose the real interop agenda, please.
>
> Glad you are here to keep people honest. This doesn't mean what you propose is the best for competition, but I'm paying attention.
>
>>
>> Best regards,
>>
>> Paul E. Merrell,, J.D. (Marbux)
>>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: oiic-formation-discuss-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: oiic-formation-discuss-help@lists.oasis-open.org
>
>



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