OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]