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

[marbux]

[continued from last post]

> Strictly speaking, "normative" clauses in a standard define the provisions
> of the standard. And provisions of the standard include the mandatory as
> well as the optional requirements.  So the "shall's" and the "should's"
> are both normative.  When reviewing a standard we scrutinize both kinds of
> clauses, since both may be implemented.

You might take up that issue with OASIS:

"Normative Statement – a statement made in the body of a specification
that defines *prescriptive* requirements on a Conformance Target....

"4. Normative Statements

"A specification broadly consist of descriptive text and Normative
Statements. The Normative Statements define what a Conformance Target
MUST do to adhere to that part of the specification, and the
descriptive text provides background information, descriptions and
examples. ..."

<http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html>.

I put in a fair amount of time awhile back looking for an
authoritative definition of "normative" in the technical standards
context for the Interop Glossary. I didn't find one. I've also
encountered a lot of folks who intend different meanings when they use
the term. In my experience, folks are all over the map on this.

So I've opted to stick with the dictionary definition until I hit
something more authoritative in context that says otherwise. That's
what OASIS did too, apparently. "Prescriptive" is the only sense for
"normative" given by my trusty Webster's Unabridged that is in the
ballpark.

If you have an authoritative reference for your definition, I'd be
happy to quote and cite it in the Glossary and change my own usage.


>> But the only room for options in specifying product characteristics
>> turns on the substitutability of the products in the market. If one
>> conforming implementation of .ODT produces a document that can't be
>> fully processed by another conforming implementation, it's a broken
>> standard.
>>
> "Fully processed" and "substitutability" are a terms of your invention,
> not ISO or WTO terms, and certainly not ODF terms.  What do you mean by
> this and on what basis do you claim this to be a requirement?  If it is
> your personal opinion, expressing your personal preferences and desires,
> then fine, I'll accept it as such.

I erred in using the phrase "fully processed" as a shorthand and
apologize for that error. A more appropriate shorthand in context
would be "equally processed." See definitions of "interoperability"
and "application-level interoperability" as well as (for citations and
reasoning) their footnotes at
<http://www.universal-interop-council.org/specification>.

As to my use of the term "substitutability of products in the market,"
I am frankly surprised that you question it. Would it help to remind
that the products under discussion are electronic documents, not the
programs that generate or otherwise process them?

Otherwise, we're off into a discussion whether standards can lawfully
bestow conformance on a pound of flour weighing four ounces when
produced by one manufacturer and 16 when produced by another. The
entire concept of standardized products goes up in smoke.

I'll happily respond with more if you still question the concept. But
given our "pound of flour" discussion already, I strongly suspect that
for a moment you fell into thinking of the programs as the products
under discussion rather than the electronic documents.

> Also, I'd argue that your assertion is tautological.  Whenever two
> products conform to the same standard, then by definition they are
> interoperable over those provisions mandated by the standard, and they are
> substitutable in those markets and for those uses which can accommodate
> the remaining dimensions of variability allowed by the standard.

That statement conflicts mightily with any authoritative definition of
interoperability I've come across. E.g., if the standard doesn't
require conforming apps to preserve markup created by other conforming
apps, and one conforming app trashes all markup created by other
conforming apps, would you still call that state of document exchange
interoperability and the electronic documents substitutable?

You might try reconciling that view with the following:

1. The ATBT prohibition against technical standards being "prepared,
adopted or applied with a view to *or with the effect of* creating
unnecessary obstacles to international trade."

2. The Asbestos Appellate Panel's holding that a technical regulation
must specify [i] *any objectively definable* "features", "qualities",
"attributes", or other "distinguishing mark"  [ii] of a product or
group of products [iii] only in mandatory "must" and "must not" terms.

3. The JTC 1 Directives requirement that standards must clearly and
unambiguously specify the conformity requirements essential to achieve
the interoperability.

4. The JTC 1 Directives definition of "interoperability," "the ability
of two or more IT systems to exchange information at one or more
standardised interfaces and to make mutual use of the information that
has been exchanged," with particular attention given to the "make
mutual use ..." clause.

5. Bob Sutor's definition of interoperability, "Interoperability is
the ability for two different and independent software applications to
exchange information *without loss of data, semantics, or metadata."*
<http://www.sutor.com/newsite/blog-open/?p=1372>.

Is this what you meant by "interoperable" and "substitutable?"

"One thing I have always dreamed to be possible is that when I write a
doc in KOffice I can then open it in OOo to use that one feature
that's useful to me and then save it and continue in KOffice without
loosing lots of data.

"Its still a dream, of course. Most features are lost on opening and
saving it in OOo, but its a nice goal :)"

KWord lead developer Thomas Zander, email to OASIS OpenDocument
Adoption Technical Committee mailing list (September 27, 2007),
<http://lists.oasis-open.org/archives/odf-adoption/200709/msg00032.html>

Or did you mean interoperability like this?

"Any comments on ODF as the default format? There was a 2004
discussion, but has anything changed after that?

"No. We will not make it our default file format. Our internal model
does not map 100% to ODT and visa versa (basically because ODT is
nothing more than a dump of OpenOffice.org's internal format). Any
data loss that happens because of saving and loading a file again will
not be accepted by our users. ...

"So you don't advise distributions to set it as default either?

"No, I'd strongly advise against making ODT the default format in
Abiword for distributions given the previously mentioned lack of 100%
feature coverage."

AbiWord developer Marc Mauer, as quoted in Rahul Sundaram, AbiWord
Team Interview, Red Hat Magazine (8 May 2008),
http://www.redhatmagazine.com/2008/05/08/abiword-team-interview/.

Or like this?

====

Implementation / Raw Score / Raw Score Percentage / Weighted Percent

OpenOffice.org 151 100% 100%
StarOffice 149 99% 97%
Sun Plug-in for Word 142 94% 96
Clever Age/MS Plug-in for Word 139 92% 94%
Wordperfect 122 81% 86%
Koffice 121 80% 79%
Google Docs 117 77% 76%
TextEdit 55 36% 47%
Abiword 48 32% 55%...

... There are no implementations that offer 100% compatibility with
OpenOffice.org.

====

Shah, Rajiv C. and Kesan, Jay P., Lost in Translation:
Interoperability Issues for Open Standards - ODF and OOXML as Examples
(September 2008),
<http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1201708> (fidelity
comparisons of ODF implementations testing only a small set of word
processing features).

[continued in next post]