Re: [oiic-formation-discuss] The importance to users of documents looking the same

[marbux <marbux@gmail.com>]

I just realized that I left a mental leap unexplained in my discussion
of the branching opportunities using the CDRF framework.

What I describe assumes that the business process automated document
assembly profile for a parallel profile would precede the development
of a pixel-perfect profile for the same profile at every profile
layer. Each pixel-perfect profile would superset the corresponding
business process profile (the subset) with the two branches of
profiles kept in synch.

Each business process profile would allow its extension to the
corresponding picture perfect supersetting profile, but only so long
as the implementations of the picture perfect profile were required to
retain the ability to write to the business process profile, i.e., to
process the business process profile as if it were the superset
profile.

CDRF, through its incorporation by references of the modal definition
of "may" in RFC 2119, also requires that implementations of the subset
profile be capable of processing the content of the superset profile
even with reduced functionality. This has the effect of requiring the
preservation of unrecognized metadata from the superset profile for
use on the return trip to the implementation of the supersetting
profile.

Just one of the many reasons for not reinventing the W3C CDRF wheel on
this TC. One really cannot comprehend CDRF without understanding the
modal definition of "may" in RFC 2119,
<http://www.ietf.org/rfc/rfc2119.txt>, which is incorporated by
reference in CDRF and was incorporated by reference in OASIS ODF 1.0,
but was substituted for the ISO/IEC Guideline definion of "may" by the
switch of requirements keyword definitions in ISO/IEC:26300
OpenDocument.

It was an interop blunder of monumental proportions. Every interop and
compatibility conformance requirement in the ODF specification was
toggled off by the editorial change from RFC 2119 definitions to
ISO/IEC Guidelines definitions.

I want interop. The notion that ISO/IEC standards must use ISO/IEC
Guidelines definitions and that that fact is a complete justification
for not dealing with the aftermath of the change is an inadequate
response for at least three reasons: [i]  the switch does not somehow
relieve ODF from the  ISO/IEC/JTC 1 Directives requirement that
international standards must "clearly and unambiguously  specify the
conformity requirements essential to achieve the interoperability;
[ii] I am not convinced that there is insufficient flexibility in the
Directives to align ODF with every other XML standard but OOXML that
require RFC 2119 definttions; and [iii] nobody seems to be into
adhering tightly to JTC 1 Directives anyway, or neither ODF or OOXML
would have been adopted as international standards without specifying
the conformity requirements essential to achieve the interoperability.

Bottom line: interoperability is fundamental  in IT standards work
both in terms of competition within the market defined by a standard
and in terms of user requirements. It also happens to be required by
law. Law does not exist in a vacuum. Law is a compendium of practical
experience in resolving real world disputes. Law simplifies the
negotiation of agreements such as the proposed TC's charter by
resolving many disagreements without any need to go to court. All that
is required is a commitment by all parties concerned to use the law as
a guide in the areas where law clearly and unambiguously resolves a
disputed item. Law is not just about lawsuits. Law is also a set of
norms for avoiding lawsuits, for resolution of disputes without
lawsuits.

Some U.S. lawyers see the pinnacle of their careers as arguing cases
in the U.S. Supreme Court. I always felt that I did my absolute best
work when I was able to resolve a client's problem without litigation.
Law is about dispute resolution; not about encouragement of lawsuits.
Law does not favor those who wait until they are sued to determine
what the applicable law is.

Best regards,

Paul E. Merrell, J.D. (Marbux)

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