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

[jose lorenzo <hozelda@yahoo.com>]

--- On Sat, 6/14/08, Peter Dolding <oiaohm@gmail.com> wrote:

> From: Peter Dolding <oiaohm@gmail.com>
> Subject: Re: [oiic-formation-discuss] Caution and Disclaimer on Interoperability
> To: robert_weir@us.ibm.com
> Cc: oiic-formation-discuss@lists.oasis-open.org
> Date: Saturday, June 14, 2008, 6:43 AM
> On Sat, Jun 14, 2008 at 8:49 AM, 
> <robert_weir@us.ibm.com> wrote:
> >
> > jose lorenzo <hozelda@yahoo.com> wrote on
> 06/13/2008 06:20:47 PM:
> >
> >
> >>
> >> I think this is a pretty important message just
> illustrated. I doubt
> >> most laypeople, when they talk about ODF
> compliance, realize this
> >> scenario is possible and actually quite possibly
> likely to happen at
> >> some point in the future.
> >>
> >> I think this is a pretty important message.
> >>
> >
> > Indeed.  It can even be done with plain ASCII text. 
> It can be done with a
> > PNG file even.  When done intentionally to hide a
> message they call it
> > "steganography".  But the same techniques
> can be used to encode extensions,
> > scripts, whatever.  I call them "embedded
> formats", the formats within the
> > format.
> >
> > There are good embedded formats.  For example, an ODF
> 1.2 spreadsheet
> > formula is just a string, from an XML perspective. 
> But within that string
> > is encoded an expression in a complex expression
> language.  But since the
> > syntax and semantics of that expression language are
> defined in ODF 1.2,
> > this is not a problem.
> >
> > But embedded formats, especially private ones, can
> certainly be abused.
> >
> > Is there anything that can be done about this, from a
> standards perspective?
> >  Saying "No undisclosed embedded formats
> allowed" is not really a testable
> > provision.
> >
> > A while back I said that conformity was the
> relationship of an
> > implementation to a standard, and interoperability was
> the relationship of
> > two implementations of the same standard with each
> other.  There are some
> > things that you will never find just testing an
> application and a test
> > suite.  The world is complex and strange enough that
> some sort of "plugfest"
> > event to bring itogether the vendors to test real
> round-trip scenarios with
> > real-world complex documents is needed.
> >
> No undisclosed embedded formats can be tested for.  Here is
> the key
> thing a undisclosed embedded format is not a issue if the
> program will
> by default no undisclosed output standard ODF that does
> work.  If its
> not on the known list its not disclosed so embed XYZ found
> that is not
> in the ODF docs would be a undisclosed section equaling
> program
> creating document with a secret.
> 
> Next about hiding settings using steganography normally
> goes flat on
> its face when face.   Why that setting will alter something
> on someone
> causing a different appearance result complete unexpected
> one day
> because by pure bad luck user lays out exactly the same
> code as what
> is needed to activate the steganographic hidden feature. 
> Section of
> the test case system should be collected trouble sum
> samples.  Ie
> report you problem documents here.   This is also one way
> of finding
> what sections people are using and is giving everyone the
> most
> problems for targeted acid testing.

I am not sure I understand what you are saying. I'm assuming a main point is that an embedded protocol is nothing but a secret of the document, perhaps like any other secret or code that the author him(her)self would have added. You implication being that it's of no concern to anyone except the author's intended audience and certainly of no concern to an ODF application.

But then what are we doing worrying about interoperability? If you replace all ODF structure designed for various purposes with your own secret sauce, then you may be following ODF technically (ie, the ODF definition of "strictly conforming" might be met), but interoperability was thrown out the window. The document produced interoperates only at a very superficial level, *gratuitously* keeping hidden from all other applications the useful content and structure users can experience only with that one application. [This is called "lock-in".]

The point I was trying to make is that any player in the market that does not want to interoperate can make that be the case rather easily EVEN WHILE FOLLOWING THE ODF STANDARD AND HAVING THEIR APPLICATION BE STRICTLY CONFORMANT. This is troublesome to me especially because there is currently a single market vendor that dominates this market. It's troubling because of the facade created that that vendor's product is certifiably conforming (which to many buyers sounds an awfully lot like being "certifiably interoperable," which is what many are demanding).

[Momentary aside: I also have made references to open source because any product that does in fact follow ODF only (or predominantly, or even partially but not wholly) at a superficial level would NOT pose interoperability problems IF it was open source (in the sense of "free software" as defined by the FSF). This is why Openoffice will generally always be interoperable even when it has bugs. Competing vendors and users can study it and adapt. Open source also keeps many things out of the product that would be undesireble to the buyer, but which when not seen (as when closed source is used) appear not to be there, yielding extra emphasis to properties like being "interoperable." A good interoperabilty framework with teeth (if achievable) would help bring competition to a single vendor controlled market as well as make closed source products that follow the *interoperability standard* more appetizing and more trustworthy to buyers. Interoperability is an
 important goal for any standard because of the value it has in the market on both sides of the transaction.]

I'll soon post a new related thread (to be named: "Strictly conforming" is not related to "interoperable") in an attempt to further study the problem of bypassing ODF while following it technically. I'll draw parallels to a standard I have looked at carefully in the past (familiar to many developers/engineers that might be paying attention) and which uses the term "strictly conforming" in a way that I find rather natural and useful: ISO/ANSI C99.