Fw: [odf-discuss] Microsoft's implementation of ODF 1.1
robert_weir at us.ibm.com
robert_weir at us.ibm.com
Tue Jan 6 10:45:13 EST 2009
odf-discuss-bounces at opendocumentfellowship.com wrote on 01/06/2009
> Sent by:
> On Mon, Jan 5, 2009 at 4:59 PM, <robert_weir at us.ibm.com> wrote:
> > odf-discuss-bounces at opendocumentfellowship.com wrote on 01/05/2009
> > 04:32:17 PM:
> >>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.
> > Hi Paul, I think the above is at the core of your argument. So I
> > understand your position perfectly, are you asserting that a standard
> > only permitted to include mandatory requirements, e.g., those
> > "shall" and "shall not" in ISO practice, or "must" and "must not" in
> > practice?
> 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.
> One key to understanding is the interchangeability, or
> substitutability, of the products in the marketplace that is the
> object of standards. E.g., a 1-pound bag of flour should weigh the
> same regardless of who produces the flour. The consumer is supposed to
> know what to expect when they buy "a pound" of something, regardless
> of the manufacturer. So too when they acquire an app whose developers
> claim to produce conforming ODF documents.
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. 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.
> 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. Whether a particular
real-world product interoperates or not is outside the realm of voluntary
standards. Similarly, a law against jaywalking does not enforce itself.
It just defines the rules for pedestrian traffic and lists the acts which
are illegal. But it is only through voluntary citizen goodwill and police
enforcement that this is enforced.
> At the same time, options are proper in at least three circumstances:
> [i] when specifying alternative methods to achieve the same result;
> [ii] when expressing tolerances; and [iii] when specifying a group of
> related products. E.g., you MAY do either this or that but the result
> MUST be X. The thread width MAY vary but MUST fall within the range of
> Y +/- Z. You MAY implement only this subset but if you do you MUST NOT
> claim conformance with the superset.
Generally, a standard should describe the results, not the methods used to
achieve them. We call this the "performance approach". 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
5. Discretionary items
The W3C has a nice Note on the subject, called "Variability in
Specifications" you might enjoy: http://www.w3.org/TR/spec-variability/
> Further, are you asserting that a standard that includes even a
> > single optional requirement or recommendation, e.g., a "should" or
> > not" in ISO practice, or expresses an implementation option, e.g.,
> > in ISO practice, is not a "real standard", or is an unlawful standard,
> > is a standard that may not be specified as a requirement for
> > procurement?
> No. "Should" and "should not" are only informational; they establish
> no normative requirements. Who can object to more information? And as
> mentioned above there are proper roles for options.
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.
> 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
"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.
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. Whether
they meet your particular need is another question entirely. Are you
baking a cake? Or doing dietetic testing of mice? Needs vary and in
writing a standard we try to balance the needs of many interests.
> Another way you might look at it is that standards are supposed to
> define markets where all can compete on equal terms because they are
> all producing the same product. The benefit to society is that with a
> more stable product, manufacturers can invest more in lowering
> production costs and thereby lowering the cost to consumers.
Certainly not. Although the goal is certainly laudable, within a standards
committee, at least in the U.S., it is forbidden to discuss things like
market impact, costs, prices, equalizing competition, etc. These are all
anti-trust red flag items and we are all warned when joining a committee
that these items are off-limits for discussion.
But I think I agree with you on the goal. But, by analogy, if you want to
reduce gun violence, you won't make much progress by drafting an ISO
standard that gives the requirement "A conforming gun shall not shoot the
good guys." The competitive problems in the market today are not caused
by bad standards. Remember, we had problems in the market long before ODF
and OOXML came around. The problems are caused by poorly-conforming
products, consumer indifference, lax procurement policies, and by
companies that benefit from the status quo. Playing around with
conformance clauses gives you very little leverage to address the root
> I think this an important point: standards are supposed to be
> agreements not to compete on the basis of product differentiation, but
> rather on price, quality, and customer service. See e.g., Allied Tube
> & Conduit v. Indian Head, Inc., 486 U.S. 492 (1988),
> <http://laws.findlaw.com/us/486/492.html>. ("Agreement on a product
> standard is, after all, implicitly an agreement not to manufacture,
> distribute, or purchase certain types of products.")
I disagree. What you describe -- competition on price, etc. -- is the
definition of a commodity. Certainly some agricultural and industrial
products trade that way. But this is not the rule. Take web browsers,
for example. HTML, CSS2, EcmaScript, etc., are all standardized.
Interoperability among browsers is improving, and compared to a few years
ago, is rather good. But the browser vendors, both commercial and open
source, still fiercely compete on the basis of product differentiation. In
fact, the elimination of vendor lock-in previously caused by the use of
proprietary dialects of HTML/CSS2 has opened it up for the smaller vendors
to distinguish themselves even more based on features.
Is this such a bad thing? I think the competition between Firefox and
Internet Explorer has been a good thing. And we have Opera, Safari and
Chrome now, each bringing their own feature set.
Remember, we've seen what it is like for everyone in the world to have the
same features in their word processor. It is called a monopoly, and we
nearly had it with Word. I'd rather not return to that world. We need
interoperability, certainly, but not at the expense of product
differentiation. We need to keep the wheel of progress turning, and we do
that by encouraging vendors to innovate. It is not an either/or question.
We need both.
More information about the odf-discuss