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

[marbux]

Resending in 3 parts over the next few minutes because Mailman has
been choking on the length.

On Tue, Jan 6, 2009 at 7:45 AM,  <robert_weir at us.ibm.com> wrote: >
odf-discuss-bounces at opendocumentfellowship.com wrote on 01/06/2009 >
07:59:19 AM:

>> Were it only so simple. No. But the product *characteristics* -- in
>> the instant case, electronic document formats -- may only be specified
>> in such terms. You have to distinguish between specification of
>> product characteristics and other aspects of a standard. >>

> Is this a definition or a requirement?  In other words, I could argue that
> product characteristics are by definition those provisions of a standard
> which are mandatory.  But that does not forbid a standard from allowing
> additional dimensions of variability.

Not sure I understand the question or the argument. Might  you clarify?

One way of reading what you said in regard to product characteristics
would be analogous to Humpty Dumpty's "it means just what I choose it
to mean – neither more nor less." I.e., is the argument that an
international standard could lawfully fall short of specifying a
complete product, that only whimsy rules what characteristics must be
specified?

The Asbestos Appellate Body decision defines "product characteristics"
in a manner inconsistent with treating the term as a synonym for
"those provisions of a standard which are mandatory." Note the "any
objectively definable ..." phrase below.

====

67 ... The word "characteristic" has a number of synonyms that are
helpful in understanding the ordinary meaning of that word, in this
context. Thus, the "characteristics" of a product include, in our
view, any objectively definable "features", "qualities", "attributes",
or other "distinguishing mark" of a product. Such "characteristics"
might relate, inter alia, to a product's composition, size, shape,
colour, texture, hardness, tensile strength, flammability,
conductivity, density, or viscosity. In the definition of a "technical
regulation" in Annex 1.1, the TBT Agreement itself gives certain
examples of "product characteristics" - "terminology, symbols,
packaging, marking or labelling requirements". These examples indicate
that "product characteristics" include, not only features and
qualities intrinsic to the product itself, but also related
"characteristics", such as the means of identification, the
presentation and the appearance of a product. In addition, according
to the definition in Annex 1.1 of the TBT Agreement, a "technical
regulation" may set forth the "applicable administrative provisions"
for products which have certain "characteristics". ...

====

Perhaps also relevant depending on what the argument is, from the same decision:

====

70. A "technical regulation" must, of course, be applicable to an
identifiable product, or group of products. Otherwise, enforcement of
the regulation will, in practical terms, be impossible. ...

====

I.e., I don't see how anyone could knowledgeably argue in good faith
that either ODF or OOXML specify the characteristics of an
"identifiable product," keeping in mind that the product of interest
is an electronic document. See e.g., the ODF v. 1.1 conformance
section:

"Documents that conform to the OpenDocument specification may contain
elements and attributes not specified within the OpenDocument
schema....

...

"There are no rules regarding the elements and attributes that
actually have to be supported by conforming applications ..."

With both ODF and OOXML, the decision as to what constitutes the
product is largely left up to individual implementers, resulting in
interoperability nightmares. So the ATBT prohibition against standards
that create unnecessary obstacles to international trade comes into
play. Are the oceans of interoperability breakpoints in those specs
necessary? What is the justification for allowing the "product" in
effect to be defined by the implementer with the largest market share
rather than by the standard?


>> E.g., a 1-pound bag of flour should weigh the
>> same regardless of who produces the flour.

> OK.  But the standard might not specify the color of the bag.  That might
> be an allowed dimension of variability and vendors might differ in what
> color bag they use.  There might also be tolerance in how finely the flour
> is ground, the protein content per gram, etc.  Depending on ones use of
> bag of flour, this may or may not be appropriate.  If you are doing
> dietetic testing in lab mice you might instead need stronger guarantees
> and adopt a profile of the standard for "1 pound bag of flour with 1%
> water content by weight and 4gm protein per ounce".  There is nothing
> wrong with that.  The need, by some users, to have a finer set of
> restrictions for a bag of flour does not make the base standard > illegitimate or not useful for those who are satisfied with the
> variability inherent in it.

Agreed, but here our analogy parts with the present state of the ODF
and OOXML specs because neither identifies or defines any product at
all.

> If there are divergent requirements, rather
> than creating one monster standard that has everything, you typically
> factor it into a family of standards, or a standard with profiles, or a
> standard with conformance classes, or a modular standard, etc.

No problem if each of the above specifies a separate product that is
responsive to market requirements. If they don't, then we need to get
down to more specific cases.

But with both ODF and OOXML, what we've got is monster specs that
don't specify any product at all. They're both woefully
under-specified.

>> Different methods might be used to manufacture the product, but the
>> end product must be the same, within the limits of tolerances that are
>> responsive to market requirements and technical feasibility. --- Which
>> is a rather complicated way of saying that either the wrenches  made
>> by one group of companies *must* be capable of interoperating with
>> those bolts and nuts made by still other companies or something has
>> gone awry in the standard setting process for nuts, bolts, and
>> wrenches, or one of the above is non-conforming. :-) >>

> > A standard does not mandate interoperability.  There is really no way it
> can.  A standard can only define conformance.

Agreed, but my point was different. To restate it another way: The
variability allowed by the standard must be responsive to market
requirements. If that conforming wrench won't interoperate with the
corresponding conforming bolt head, then the variability allowed by
the standard collides with the prohibition against standards that
create unnecessary obstacles to international trade.

I'll also note here that an international standard for electronic
documents not only can but must mandate "the conformity requirements
essential to achieve the interoperability," in the words of JTC 1
Directives. So it is clear that the standard must not only specify a
product but also the application behavior necessary for its
interoperable exchange.

> Whether a particular
> real-world product interoperates or not is outside the realm of voluntary
> standards.

I can go quite a way down that path but can't give the statement
unqualified agreement. As one example, you and I have previously
discussed my opinion that JTC 1 Directives Annex I requires not only
that interoperability be demonstrable but also demonstrated if
necessary to have high confidence that interoperability conformance
requirements are adequate. I'll note here to save you the bother that
you disagreed.

As another example, antitrust law could have a lot to say about a
voluntary standards organization and its participants that
intentionally broke interoperability with a vendor's app to
disadvantage that vendor in the market. See e.g., closely analogous
case in the U.S.: Allied Tube & Conduit v. Indian Head, Inc. 486 U.S.
492 (1988), <http://laws.findlaw.com/us/486/492.html> (steel conduit
vendors stuffed the voluntary standard organization's ballot box to
exclude PVC conduit manufacturer from the market); see also U.S.
Federal Trade Commission and Department of Justice, Antitrust
Guidelines for Collaborations among Competitors (April, 2000), pg. 2
n. 5, <http://www.ftc.gov/os/2000/04/ftcdojguidelines.pdf>. ("These
Guidelines take into account neither the possible effects of
competitor collaborations in foreclosing or limiting competition by
rivals not participating in a collaboration nor the possible
anticompetitive effects of standard setting in the context of
competitor collaborations. Nevertheless, these effects may be of
concern to the Agencies and may prompt enforcement actions.")

And I somewhat hazily recall statements that a voluntary standard
organization can sue a vendor falsely claiming conformance with
interop conformance requirements and using the voluntary standard
organization's trademark if the use of the trademark is conditioned on
conformance. But that's an issue I have not personally researched.

There may be other exceptions that either don't come to mind or that I
have not run across in my research.

 > Generally, a standard should describe the results, not the methods used to
> achieve them.  We call this the "performance approach".

I can also ride a fair bit of the way with you on that point. The
origin of that approach traces to economic theory embodied in
competition law. The principle of origin is that vendors of
standardized products should be encouraged to compete through more
efficient means of production and marketing, thereby lowering costs to
consumers.

But the performance approach is not a blanket authorization to
under-specify a standard. E.g., there is no performance approach
exception to the ATBT prohibition against standards "prepared,
adopted, or applied with a view to or with the effect of creating
unnecessary obstacles to international trade." Likewise, there is no
performance approach exception to the corresponding section of JTC 1
Directives, the  requirement that IT international standards "clearly
and unambiguously specify the conformity requirements essential to
achieve the interoperability."

And on the factual precedent end, RFC 2119 --- which was incorporated
by reference in OASIS ODF 1.0 --- recognizes an exception from the
performance approach for interoperability:

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

<http://www.ietf.org/rfc/rfc2119.txt>.

A useful rule of thumb here might be that responsiveness to market
requirements trumps the performance approach when they collide. See
e.g., World Trade Organization Committee on Technical Barriers to
Trade,

 Decisions and Recommendations Adopted by the Committee Since 1
January 1995 (23 May 2002),
<http://docsonline.wto.org/imrd/directdoc.asp?DDFDocuments/t/G/TBT/1R8.doc>:

"In order to serve the interests of the WTO membership in facilitating
international trade and preventing unnecessary trade barriers,
international standards need to be relevant and to effectively respond
to regulatory and *market needs,* as well as scientific and
technological developments in various countries. They should not
distort the global market, have adverse effects on fair competition,
or stifle innovation and technological development. ...

"11. Accordingly, it is important that international standardizing bodies:

"Take account of relevant regulatory or *market needs,* as feasible
and appropriate, as well as scientific and technological developments
in the elaboration of standards[.]"

> Certainly, with
> industrial standards, tolerances are commonly expressed.  This is a
> dimension of variability.  With markup standards, the recognized
> dimensions of variability are broader and include:

> 1.      Classes of product
> 2.      Profiles
> 3.      Modules
> 4.      Levels
> 5.      Discretionary items
> 6.      Deprecation
> 7.      Extensibility

> The W3C has a nice Note on the subject, called "Variability in
> Specifications" you might enjoy:  http://www.w3.org/TR/spec-variability/

I would not choose the word "broader." It is in my opinion a
difference in kind rather than magnitude. E.g., all of the above and
more could undoubtedly be found in standards for physical products.

I also approve of your use of "include." It's an incomplete list,
particularly for apps that both read and write documents. (The W3C is
more than somewhat biased toward browser developers and browsers have
only very limited editing capability.)

E.g., for implementations that write to ODF, preservation of
conformant markup is a dimension of variability in critical need of
definition in the spec. And the word "supported" in the conformance
section needs to be defined in a manner that does not allow
destruction of conforming markup except by user initiated action, etc.

[continued in next post]