[odf-discuss] OOXML: The next step

[marbux]

On Tue, Apr 15, 2008 at 7:02 AM, <robert_weir at us.ibm.com> wrote:

>
>
> > 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.
> >
>
> A standard does not grant conformance.  That is not the job of an SDO like
> OASIS or of JTC1 or ISO.  We do not evaluate implementations, rate them,
> score them, accredit them, label them as conformant or not.  That is not
> what a standard does.  What you are talking about here is a conformity
> assessment methodology, of which the standard is one part, but which also
> typically comprises other documents, test suites, etc., and which is
> administered by a 3rd party.
>

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;"?


>
> Note as well that the primary conformance class for ODF is that of a
> conformant document.  We can define a conformant document without regard to
> any software application.  You won't find an analogue to this in any of your
> WTO text talking about physical standards, but this is a reality of IT
> standards.  Similarly, we can have a standard that describes the codec for a
> DVD, while not describing the physical requirements of the disc, or without
> describing the rutime requirements of the player.  Why?  Because the overall
> ecosystem around DVD includes encoders, duplicators and many other such
> functions that are invoked in production of DVD's before they ever reach the
> consumer.
>
> In other words, ODF is a document interchange format, not a standard for a
> word processor.
>

I can agree that it is not invariably necessary to specify application
behavior. However: [i]  when there is an unavoidable choice between
specifying application behavior in conformity requirements necessary to
achieve interoperability/interchangability and omitting conformity
requirements necessary to  achieve the interoperability, JTC 1 directives
and the Agreement on Technical Barriers to Trade command that the
application behavior be specified with no applicable exception identified;
and [ii] the vast majority of XML standards agree through their
incorporation by reference of RFC 2119 requirement keywords definitions. See
e.g., RFC 2119 section 6, <http://www.ietf.org/rfc/rfc2119.txt>:

Imperatives of the type defined in this memo must be used with care and
sparingly.  In particular, they MUST only be used *where it is actually
required for interoperation* or to limit behavior which has potential for
causing harm (e.g., limiting retransmisssions)  For example, *they must not
be used to try to impose a particular method on implementors where the
method is not required for interoperability.
*


> Similarly, for ODF there are UI-less server-based applications that scan,
> index, generate reports from, convert, pack/unpack into a relational
> database, etc. ODF documents without ever needing to display or render an
> ODF document.  For them, the detailed description of the ODF schema given in
> the standard is complete and unambiguous, described in a formal schema
> definition language, RELAX NG.
>

Nope. It's neither complete nor unambiguous for them. The ODF conformance
requirements call only for validation against the schema after all foreign
elements and attributes are removed. The ODF validation method is inadequate
as an interoperability conformity assessment methodology because it does not
provide a means of validating real-world ODF documents, only their stripped
remnants. In other words, here we deal with yet another interoperability
breakpoint presented by the classification of documents containing
vendor-specific extensions as conformant. As said on Wikipedia and as is
self-evident:

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

<http://en.wikipedia.org/wiki/Validation>.

>
> I think you are still missing the point on demonstrable versus
> demonstrated.  There is nothing in JTC1 that requires a pre-existing
> implementation of a standard, let alone two different implementations that
> can demonstrate interoperability.  Certainly this is a best practice.  But
> it isn't a requirement.  So JTC1 cannot then require an actual demonstration
> of interoperability.


I haven't missed the point; I'm just saying that it doesn't hold water. See
the portions of the Directives I quoted before and Directives Appendix C
governing conformity assessment procedures  (incorporated by reference into
Appendix I, which is what we have been quoting back and forth at each
other).

Short story here: we discuss exit criteria for standards, and to satisfy the
exit criteria "there may be need to use an interoperability assessment
methodology *in demonstrating *interoperability between two or more IT
systems *in practice*." E.g., how are the JTC 1 NB's to ensure that a draft
standard "clearly and unambiguously specifies the conformity requirements
essential to achieve the interoperability" without a demonstration? Annex I
includes a very long paragraph specifying just how detailed the testing
requirements may permissibly be to ensure that conformity requirements
actually do specify the conformity requirements essential to achieve the
interoperability.



>   Demonstrable interoperability is based on whether the requirements of
> the standard are testable or not.  If I say in the standard, "The widget
> shall be big" then this is not testable.  But if I say 'The widget shall be
> 30cm +/- 1%", then this is testable.  Where conformity is defined in terms
> of testable requirements, then interoperability is demonstrable.  Note that
> with ODF, even vendor extensions have requirements, such as being in a
> different namespace, and these requirements are testable.
>

You actually identify the totality of the mandatory conformity requirements
in ODF for vendor-specific extensions, so your "such as" is inappropriate.
I.e., this is not an example of multiple applicable requirements; it is the
*only* applicable requirement.

Furthermore, there is no validation methodology identified by the ODF
standard for vendor-specific extensions so you posit an entirely
hypothetical circumstance while espousing an argument for keeping ODF
interoperability entirely hypothetical rather than being achieved and
demonstrated. But the actual requirement is that international standards
must "clearly and unambiguously specify the conformity requirements *essential
to achieve* the interoperability." How is one to determine what conformity
requirements are essential to achieve interoperability without testing? We
deal here with a specification that is considerably more complex than the
allowable tolerances for the length of a widget, which one might assume with
some confidence actually required some testing to arrive at as well.

Your argument reduces the JTC 1 requirement of interoperability to a
permissible mere claim of demonstrability. But that clashes not only with
market requirements for standardized formats but with what the Directives
actually say:

These Directives shall be complied with in all respects and *no
deviations*can be made without the consent of the
Secretaries-General.

...

A purpose of IT standardization is to *ensure that products available in the
marketplace* *have characteristics of interoperability*, portability and
cultural and linguistic adaptability. *Therefore, standards which are
developed shall reflect* the requirements of the following Common Strategic
Characteristics:

   - *Interoperability*;
   - Portability;
   - Cultural and linguistic adaptability.

One can argue until the cows come home that the requirement of
interoperability is merely hypothetical. But phrases like "no deviations,"
"ensure," "products available in the marketplace" and "shall reflect" all
cut against such an argument. The Directives are concerned with reality, not
with mere claims or attempts to split fine hairs over the meaning of terms
like "demonstrable" and "demonstrating" when read in isolation from their
surrounding text.  I.e., the word "demonstrating" in the text is immediately
followed by the phrase "in practice."

However, it is enough for my purposes that you raise such arguments in light
of your previous recognition that "[i]f you use extensions you know you will
not be interoperable" yet would allow documents containing such extensions
to be classified as conforming ODF. The message is clear that you view
vendor-specific extensions as being more important than interoperbility. In
other words, nothing will change on the ODF TC in regard to fulfilling the
market and legal requirements for interoperability of ODF implementations
under IBM's leadership of the TC. If I use implementation X and receive an
ODF document generated by implementation Y, the ODF specification will
provide me no assurance that there will be no degradation of data when I
open the document for editing.


> I'm not sure I see the applicability of an asbestos case to ODF,


The applicability is that the WTO Appellate Body was pronouncing generally
on the meaning of a "technical regulation" as defined in the Agreement on
Technical Barriers to Trade, a definition that legally valid international
standards must also adhere to, whether they be standards for hazardous
materials or standards for information technology.

If you wish to argue that some exception has been created for information
technology, I'm all ears. But I would appreciate it if you would provide a
citation. I have looked at some length for such an exception and have never
found one.


but certainly ODF has and will continue to have optional as well as
> mandatory parts.  For example, it would be silly of us to require that
> AbiWord implement spreadsheet functionality as well as the word processor
> functionality.  And we should be happy to see an ODF to DAISY talking book
> convertor be called conformant even if it doesn't display presentation
> animations visually in the way that OpenOffice does.


I have no issues with the fact that ODF specifies several different
products. See e.g., WTDS 135 EC - Asbestos (a technical regulation [or
international standard] must "be applicable to an identifiable *product, or
group of products."

*That is not the issue. The issue is the lack of specification of mandatory
product characteristics in the ODF specification. See e.g., this so-called
"conformance" requirement:
*
*There are *no rules* regarding the elements and attributes that actually
have to be supported by conforming applications, except that
applications *should
not* use foreign elements and attributes for features defined in the
OpenDocument schema.
*
*I don't think I need to explain what "no rules" means. Let's just say it
falls somewhat short of the ATBT requirement that international standards
specify all product characteristics only in mandatory terms.

"Should not" is also not a mandatory conformance requirement, of course,
under the definitions incorporated by reference into ODF.  There is nothing
in the ODF specification forbidding a vendor like Microsoft from including
no elements and attributes specified in ODF whatsoever and using only OOXML
markup instead. In terms of mandatory product characteristics, ODF is only a
container for just about anything a vendor wishes to include.

The only relevant conformance requirement is that such maneuvers must be
conducted in the implementing application's unique namespace(s).  Such a
document would still validate against the ODF schema since all foreign
elements and attributes may permissibly (indeed as a practical matter must)
be removed prior to validation against the schema.

Of course at the moment Microsoft does not need to engage in such
skullduggery, having obtained its own signed but otherwise blank check from
JTC 1. But if governments insist on ODF support, Microsoft Office Group
Product Manager Gray Knowlton has reportedly already said it will provide
such support, albeit with vendor-specific extensions.

Also, if individual governments mandate the use of ODF instead of Open XML,
Microsoft would adapt, Knowlton said. The company would then implement the
missing functionality that ODF doesn't support. However, those extensions
would be custom-designed and outside of the standard, which is counter to
the idea of an open document standard, Knowlton said. "Disastrous? No. But
definitely not preferable," he said.

<http://www.pcworld.com/article/id,141424-c,opensource/article.html>.

As drafted, what really defines ODF's product characteristics is the
implementation with the largest market share's exercise of the near-absolute
developer freedom built into the specification. But that may not be
OpenOffice.org much longer. It may quickly become Microsoft Office and ODF
may become OOXML in an ODF container. There is nothing in the ODF
specification stopping Microsoft from doing so, just as there is nothing
stopping others from parking ODF in an OOXML container.

The bedrock truth is that both ODF and OOXML are standards in name only.
Neither specifies all characteristics of a product or group of products in
mandatory terms. I think it unmistakable from what you have said that IBM
has no desire to change that situation in ODF v. 1.2.  Freedom to innovate
trumps interoperability again.

What is truly sad is that freedom to innovate and interoperability are not
mutually exclusive. All it takes is a defined superset profile and
compatibility modes in implementations for document interchange purposes.
Then software users could have their choice on a per-document basis whizzy
new features in a particular app and interoperability among their selection
from a range of applications.

It's really too bad that IBM does not want to offer its customers that
choice. ODF interoperability will remain a myth for yet another version.

Best regards,

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20080415/0f2d5d4a/attachment.htm