Re: [oiic-formation-discuss] Caution and Disclaimer on Interoperability

[robert_weir@us.ibm.com]

jose lorenzo <hozelda@yahoo.com>
wrote on 06/12/2008 12:26:37 AM:


> To repeat more clearly, don't expect to succeed in
> withholding the "conformancy" label from any monopoly
> vendors wanting to embrace and extend with intent to
> extinguish. Instead, look towards this work with OASIS
> as a way to make things easier on groups that really
> do want to standardize and interoperate.
> 

Hi Jose, a few things to note.
 
First there is no way that a standard
can distinguish good, competitive, progressive, innovative extensions from
evil, monopolistic, embrace and extend extensions.  If we disallow
all extensions, then we essentially say that every word processor must
have the same feature set (You can have any color you want so long as it
is gray).  We would also would prevent the ability of mixing ODF with
other markup languages, even if they were open standards as well.  

For example, I've heard a lot of interest
in mixing XBRL, the now-mandated markup language in the US for annotating
security filings, with ODF.  But if ODF cannot allow other markup
in a foreign namespace, then this could not be done.

So in the end, if we try to make moral
distinctions in the standard, we'll be continually frustrated.  We
cannot force anyone to do anything.  All we can really do is make
definitions and give them a label, and hope that these definitions have
enough market relevancy that they are adopted.

However, we do have a number of tools
available to us, to make these kinds of distinctions.  For example,
there was a suggestion yesterday to define an ODF/A profile for archiving,
analogous to PDF/A.  This profile would forbid certain non-portable
constructs in ODF documents conforming to this profile, among which I assume
would be extensions.  

Similarly, the concept of "strict
conformance" is already well-defined.  This is defined as:

"Strict Conformance – conformance
of an implementation that employs only the requirements and/or functionality
defined in the specification and no more (i.e., no extensions to the specification
are implemented)."  (http://www.oasis-open.org/committees/download.php/305/conformance_requirements-v1.pdf)

So the proposed committee, when creating
a conformity assessment methodology document could certainly do so from
the perspective of strict conformance as well as general conformance.  But
again, we're defining, we're not mandating.  It would be up to our
audience -- the procurers, vendors, users, etc., --  to determine
which mode of conformance was important to them.

-Rob