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

[jose lorenzo <hozelda@yahoo.com>]

--- On Wed, 6/18/08, marbux <marbux@gmail.com> wrote:

> From: marbux <marbux@gmail.com>
> Subject: [oiic-formation-discuss] PROPOSAL -- Name change for proposed TC
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Wednesday, June 18, 2008, 4:18 PM
> PROBLEM STATEMENT
> 
> The name for the proposed TC is currently proposed as
> "ODF
> Implementation, Interoperability and Conformance Technical
> Committee"
> ("OIIC TC")
> 
> That is a mouthful unlikely to be understood by those who
> do not
> understand the technology and know what the acronym
> "ODF" means.
> 
> PROPOSAL
> 
> I propose instead that the TC be named the
> "OpenDocument Exchange
> Formats Technical Committee ("ODEF TC").
> 
> JUSTIFICATION
> 
> 1. By using "OpenDocument" rather than
> "ODF", the alphabet soup is
> removed from this existing proposed name and the
> relationship of this
> TC to the work of the ODF TC's work is more explicitly
> stated.
> 
> 2. The term "exchange formats" encapsulates the
> range of work
> contemplated for this TC in terminology more easily
> understandable to
> far more people, yet still distinguishes this TC's name
> from the ODF
> TC's name. .

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

> 
> 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.

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.

> 
> 4. It is impossible for this TC's profiles to maintain
> compatability
> with the work of the ODF TC if the goals of
> interoperability and
> application-neutrality are to be fulfilled. All of the
> "may" and
> "should" clauses and the ocean of passive voice
> sentences in the ODF
> TC's work mask hard-coded programming decisions made in
> existing
> implementations. These areas of under-specification
> represent
> dependencies on non-interoperable implementations of  the
> ODF
> standard...

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.

> ...There are also huge black holes in the ODF
> specification,
> such as the lack of an identified interoperability
> framework that
> specifies conformance requirements and application behavior
> necessary
> to achieve interoperability.

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.

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.

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.

> 
> 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.

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).

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

> 
> 5. The name OpenDocument Exchange Formats differs from the
> name given
> to a very closely-related project under way conducted by
> European
> Union governments only by the lack of a space between the
> words "open"
> and "document" in the name I propose. This
> proposed TC is obviously
> intended to respond to the requirements established by the
> E.U.
> government IT departments and procurement officials
> participating in
> that effort. E.g., they required that profiles and
> conformity
> assessment procedures be developed and that a single
> standard be
> developed based on ODF that responds to the needs of all
> vendors.
> Rejection of OOXML was explicit. The importance of
> vendor-neutral
> interoperability was stressed in the requirements.

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.

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.

> 
> IBM and Sun, through the European Committtee for
> Interoperable
> Systems, instigated an antitrust investigation of Microsoft
> that has
> resulted in Microsoft bowing to the wishes of the E.U.
> government IT
> and procurement officials committing to development of
> native file
> support for ODF 1.1 in Office 2007, and joining the ODF TC
> to work on
> ODF 1.2. ODF 1.2 when adopted will be quite different from
> the current
> draft in order to remove interop barriers with Microsoft
> Office.
> Substantial reprogramming of both OOo and MS Office will be
> required.

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

> 
> The ODEF name I propose.is intended to establish this
> TC's work as
> responsive to the market requirements specified by E.U.
> government and
> the antitrust investigation's fruit, rather than to the
> requirements
> of the big vendors who created the interop mess in the
> first place.

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.

> 
> Those who wish to thoroughly examine the requirements
> established by
> E.U. government for Open Document Exchange Formats can
> start on this
> page, which links all related materials
> <http://ec.europa.eu/idabc/en/document/6474>. Those
> who wish only a
> quick overview may visit this page,
> <http://ec.europa.eu/idabc/servlets/Doc?id=27956>,
> and skim the eight
> slides used in Dr. Barbara Held's report to the plenary
> session. Dr.
> Held is the E.U. official with lead responsibility for
> coordinating
> the interoperable exchange of documents throughout all
> levels of E.U.
> governments.
> 
> 6. This proposal in essence asks the big vendors to
> disclose whether
> this proposed TC or the ODF TC is the TC that will actually
> be working
> on responding to the interoperability requirements of E.U.
> government.
> There is an interoperability agenda that has not been
> disclosed by the
> big vendors and I wish to know whether this TC proposal is
> anything
> more than a smoke screen to distract attention from the TC
> where the
> big vendors are making the real interop decisions.

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

> 
> What is the utility of this TC if the real
> Microsoft-Sun-IBM-Novell
> interop agreement is being negotiated on the ODF TC using
> ODF 1.2 as
> the document that records the agreement? Any earlier
> version of ODF
> will be obsoleted by that agreement because of the
> numerous, serious,
> and thoroughly documented interop barriers between the OOo
> code base
> and the code base of Microsoft Office that are embodied in
> the earlier
> versions of ODF.

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).

> 
> 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)
>