Thoughts about Interoperability (Part 2)

[Svante Schubert <Svante.Schubert@Sun.COM>]

I would like to follow-up on my earlier mail on the list.

After we might have archived step one, splitting ODF complexity by finding the smallest disjunctive testable pieces of ODF

• for ODF package testing ZIP, signature, encryption, metadata and
  
• for ODF XML testing components as image, hyperlink, table,
  
• for OpenFormular testing a single formula

it will easier to analyze each single part and create a test for it (AFAIK for OpenFormula already tests exists).

Notable about these tests is that they are intended to test various ODF implementations, therefore they should not rely on implementation details (black box tests).
A test would simply consist of as test description, which would reference to one or more test documents.
Test description would explain a test scenario, which is from on ODF user the expected allowed manipulation of the ODF format. For instance for the table feature it would be the adding if a row to a table.
We might say we specify the expected user behavior (the controller) upon the ODF format (the model).

Let's start giving a example by describing the test for the ODF Package feature encryption.
Basic info on encryption: In general encryption is used that a document can not be viewed, edited by anyone else aside of those holding the key (password). A document can be either encrypted or not.

The first idea of a test would be to any kind of test document encrypt it, than decrypt it and if the output is equal to the input the tests passes. There would be only two methods defined:
encrypt(String password)
decrypt(String password)

On a second glance any ODF implementation might claim to implement encryption but by doing nothing when one of the above methods would be called, would still pass the test. As the encryption has a random part within, we can use a encrypted test reference.
Instead the test would only ask to encrypt or decrypt and a test implementation (ODFDOM) would test if the ODF implementation worked correctly.

Helpful for the test scenario and the user would an additional function
boolean isEncrypted()

There might be other methods following due to the fact that different algorithms might be used, but software development is not a waterfall process and I would add those methods to a later iteration, when implementing the test.
The rule of thumb is that all parts of the model (ODF XML) that a user might want to change, should be covered by a test description and methods.

The nice side effect of those high level ODF functionality description by methods (the controller) is that all of these combined would form an ODF API. Such test description could be automatically read, to load test documents and trigger the methods being named.
Checking conditions being defined in the tests, the syntax is uncertain yet, but can be arbitrary, I would suggest XML to map it easily.
Bart has already started to work on ODF 1.2 encryption testing:
http://tools.oasis-open.org/version-control/browse/wsvn/oic/TestSuite/branches/barth/odf12/files/#_TestSuite_branches_barth_odf12_files_

The ODF API would have the nice side effect that ODF extensions might rely on a same API to manipulate ODF.
We can be sure, that in the end the perfect interoperability for a user would be archived when aside of the model as well the controller and the view are being specified.

On the last call I suggested to find the test description for an ODF image as a first example of an ODF XML Feature.
The nice thing, the ODF image does in general exist only from two elements
 <draw:frame><draw:image/></draw:frame>
The frame that provides the size and the image providing the source. There might be multiple images within the frame as the application might choose the one it supports best (similar to the HTML 5 video element <video><source/></video>).
The test would now describe all expected user behavior upon the image, which is identically to the manipulation of its element and attribute content. The possible data is given by the ODF spec only the behavior is not specified.
To help us in this task, I will continue to work on the schema2template tool to add functionality to provide easily a list of all possible elements and attributes for an image.
Therefore we might want to start to write test descriptions for the four ODF package (ZIP, signature, encryption, metadata).
Having test descriptions and documents would ease the life of ODF developers to implement features and similar provide buyers of ODF technology a scale to build their contract upon (these set of features are bought and the test have to pass).

To be continued..

Regards,
Svante