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] "Strictly conforming" is not related to "interoperable"

> My concern is the use of terms like "strictly conforming" within a
> context to imply interoperability when in fact the two are quite
> unrelated, at least as "strictly conforming" for ODF is defined
> today (which would be analogous to the C definition of strictly
> conforming, which was reasoned above as having nothing to do with
> the ability of two C programs to *interoperate* at any level whatsoever).

An important concept is "allowed range of variability" that a standard allows implementations.  You might think, why have any variability at all?  Why not require that all implementations of a standard be precisely defined, with no allowed variability?  The reason typically is that 1) It would cost too much for implementors (and eventually consumers) and 2) It is not needed.

Take for example light bulbs.  These, in the US at least, are defined by a national standard that specifies bulb size, threading, axis of thread to the bulb, etc.  But these are all specified with certain a tolerance, +/- 1% or something like that.  Why?  Because the cost to manufacture light bulbs with greater precision than this would drive up the cost.  And with the specified tolerance, interoperability is good enough.

You see similar trade-offs in C/C++.  What size is an integer?  It is implementation defined.  Now the standard could have defined that.  Java certainly did.  But it was decided to allow this range of variability because the cost (in run time performance and storage) of mandating non-native integer sizes was too great.

So with ODF, what is the rang of variability?  There is the variability explicitly allowed by the standard itself, the things that are optional, the things that are implementation defined.  And then there are the extensions.

Strictly conforming disallows the extensions.  So it does reduce the range of variability.  But it doesn't eliminate it.  So I think there is a relationship there, but not one which in itself guarantees interoperability.


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