[odf-discuss] Microsoft's implementation of ODF 1.1

[marbux]

On Mon, Jan 5, 2009 at 11:32 AM, Jomar Silva
<jomar.silva at br.odfalliance.org> wrote:
> I really support Rob's proposal, and you misunderstood it.
>
> His proposal was presented to solve the 'application specific' implementation of a lot of ODF attributes. It solves the problem, stating that all 'application specific' implementation must have its documentation available and if the responsible for the implementation thinks that his feature is important/relevant to most users, it is recommended that his documentation is submitted to the ODF TC as a proposal.
>
> At least in Brazil, during the OOMXL discussion we have a lot of troubles regarding application behavior and application specific implementation, because it is a "dark area". Rob's proposal put some light on it :)

Application-specific elements and attributes are the antithesis of an
IT standard. Having documentation available for elements and
attributes not specified by the standard does nothing for the quality
of the standard. As Rob said to Microsoft's Doug Mahugh in regard to
Microsoft's later release of documentation for information omitted
from DIS-29500:

"But the qualities of the format were set the day the standard was
approved by Ecma. The standard does not gain capabilities by Microsoft
writing code. Microsoft applications may gain capabilities, but the
standard is what it is, and is as compatible as it is going to get the
day it was standardized."

<http://www.robweir.com/blog/2007/03/compatibility-according-to-humpty.html?showComment=1173047580000#c7339285106957530171>

I'm sorry that I must disagree with you. I did not misunderstand what
Rob said on this list previously. Please read my entire conversation
with Rob in the thread I quoted from. Rob vigorously advocated for
implementations that are incapable of writing to unextended ODF being
classified as conformant.

See e.g., <http://lists.opendocumentfellowship.com/pipermail/odf-discuss/2008-April/007361.html>.
("In other words, I don't believe
that the JTC1 requirements prevent a standard from defining
conformance in a way that allows conformant applications from also
allowing vendor extensions.") See also
<http://lists.opendocumentfellowship.com/pipermail/odf-discuss/2008-April/007366.html>
("Note that with ODF, even vendor
extensions have requirements, such as being in a different namespace,
and these requirements are testable.")

Near the close of the conversation, I asked Rob:

"I will close by asking whether you see a benefit to be gained in
continuing this conversation? My perception of your position (and
please tell me if I have this wrong) is that ODF 1.2 under your
leadership: [i] will grant conformant status to vendor-specific
extensions; [ii] will grant conformant status to editors that do not
support the complete schema for a given application type; [iii] will
not clearly and unambiguously specify the conformity requirements
essential to achieve the interoperability; [iv] will not require that
implementations claiming conformity demonstrate the interoperability;
and [v] will not specify all characteristics of the ODF file formats
in mandatory terms.

If I have correctly understood your position on these issues, I have
sufficient information to form an opinion as to the direction the ODF
TC is heading."

<http://lists.opendocumentfellowship.com/pipermail/odf-discuss/2008-April/007365.html>.

Rob objected to one clause in that summary of his position and I
suggested the following clarifying language:

"Pardon the careless wording, please. Does this rewrite of item 1 fix
the objection? "[i] will classify documents containing markup for
vendor-specific extensions as conformant;"?

Rob did not reply so I assume that the rewrite met his concerns with
my summary of his position.

In fact, Rob went so far in that conversation as to characterize ODF
as a vocabulary for development of profiles, as opposed to an IT
technical standard:

"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.  Maybe archivists want to express the
requirement that all fonts be embedded and that no object embedding
(OLE) is used, and no macros or script is used.  So, something similar
to PDF/A.  If so, ODF should provide a conformance class to express
that technical requirement. And so on.  We can do these in the
standard itself, or as separate profiles.  But I don't think we can
express a prohibition against proprietary extensions as a technical
requirement."

<http://lists.opendocumentfellowship.com/pipermail/odf-discuss/2008-April/007307.html>.

A "standard" that allows vendors to claim conformance while writing
application-specific elements and attributes is not a standard.
Standards are about uniformity, not about product differentiation. ODF
and OOXML are not true standards precisely because do not specify all
characteristics of an identifiable product or group of products only
in mandatory "must" or "must not" terms.

Interoperability is not a feature of an IT standard; it is the very
essence of an IT standard. As was said by Microsoft standards attorney
David Rudin:

"The ultimate purpose of a software standard is to enable
interoperability between different products and services.  If there is
no need for interoperability, there is little if any need for a common
standard.  The point of a standard is to make it possible for devices
and services from different providers to work together."

<http://standardslaw.com/wordpress/?p=17>

Or as was said by the IBM-backed European Committee for Interoperable Systems:

"Interoperability is a cornerstone of the ICT industry. In today's
networked ICT environments, devices do not function purely on their
own, but must interact with other programs and devices. A device that
cannot interoperate with the other products with which consumers
expect it to interoperate is essentially worthless. It is
interoperability that drives competition on the merits and innovation.
The ability of different computer products to interoperate allows
consumers to choose among them. Because consumers can choose among
them, interoperable products must compete with one another, and it is
this competition that has driven innovation in the software industry."

The problem really is that the big vendors do not practice what they
preach. With both ODF and OOXML, interoperability is a "someday"
thing.

Best regards,

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