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

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

On Thu, Jun 12, 2008 at 6:54 AM, <robert_weir@us.ibm.com> wrote:

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

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.

The C (Programming Language) standard is a treaty between the developers of C compilers and programmers writing C programs (to be compiled by those compilers). It lays obligations on both parties. It requires programmers to stick to certain rules when writing C code. It requires compiler writers to provide certain functionality. It also lays down certain areas that are defined by a particular implementation (compiler) - the standard itself doesn't say what the behaviour must be, but it does say that the compiler writer must define what the behaviour of their compiler is. Sometimes it lists the options -- other times, it does not. Further, it provides information that tells a programmer which parts of their code may work differently on different implementations, and which parts of their code will work the same on all (conforming) implementations.

Translating from C to ODF, that would mean that the standard is a treaty, first and foremost between users of ODF-compliant software packages and the developers of those packages. Secondarily, it would give some information about how different packages would treat the same ODF-compliant file - where there would be differences (e.g. fonts) and where there would be commonality (section headers need to be distinguishably be section headers -- possibly a poor example, but the best I could come up with on the spot). Adopting this view of the world, ODF would tell users that if they stick with certain features, then the documents they produce will be portable between ODF software packages. If they insist on using some other features, the portability of those documents will be reduced. This helps everyone - it limits the workload on the writers of the software packages (they do not have to handle esoteric extensions that are outside the standard), while providing users with both guarantees and warnings. Of course, there are difficulties with how to actually indicate which features that a user is using are not strictly ODF conformant - or are in nebulous territory - is hard; very hard.

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.

Pardon me if my inexperience with XML shows through, but is this not stuff that would be handled in some way by XSLT or an equivalent piece of technology. That is, if you use an XML 'Schema' (is that the correct word for things like XBRL?) in the ODF document, then you also need to provide something that provides appropriate formatting guidelines for that material -- in my limited understanding, that something being an XSLT or similar specification of how to transform and treat the 'higher level' (XBRL) notation into a 'lower level' formatting notation (is taht ODF. or something working at a lower level than ODF?).

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.

This is where the treaty comes in...The standard will specify what both sides can expect, and where both sides can innovate. Where the sides are the ODF software writers and the ODF software users.

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.

oiic-formation-discuss message