1. Creating a set of sample documents for the OpenDocument specification Lotzi Bölöni School of Electrical Engineering and Computer Science University of Central Florida

2. Project  Cooperation between Intel and the Netmoc lab at the University of Central Florida.  Objectives: –Develop a set of sample documents which cover the specification –They should come with a documentation of the expected behavior:  Sample rendering  Plain text description –Documents should not be application specific  Application specific metadata should be removed –We strive to make each document human readable XML –We try to present them in an easily browse-able manner

3. Development team  Intel –Waldo Bastian  UCF: –Lotzi Bölöni (coordinator) –Yi Luo (current developer of samples) –Majid Ali Khan (web framework, former developer of samples)  KDE –Thomas Zander (KWord samples, xml file description, xml file editor, stylesheet for converting xml to html, script to summarize results).  Outside contributions always welcome!

4. Location and status  Available at –http://netmoc.cpe.ucf.edu/Projects/OpenDocument/TestSuite.htmlhttp://netmoc.cpe.ucf.edu/Projects/OpenDocument/TestSuite.html  Mailing list: –http://i2lab.ucf.edu/mailman/listinfo/opendocument-samplehttp://i2lab.ucf.edu/mailman/listinfo/opendocument-sample  Approximately 240 tests available currently, covering most of the word processing, presentations and drawings  Delayed: spreadsheets (due to the lack of content model)

5. What does a sample contains:  Name of the sample  Description –What does a test check –What should be the desired output  Screenshots –Rendering of the test in various processors –OpenOffice 2.0.2 and KOffice  Reference –Where in the OpenDocument specification is the expected behavior described

6. How does a sample document look:

7. A quick peek at the results (not exactly pretty)

8. Sources of problems  Ambiguous and unclear specification... probably most of the problems.  A source of problems is that frequently there are more than one way to implement a functionality in the OpenDocument specification –The applications prefer one way – the other approach is incompletely supported. –Example: OpenOffice prefers to implement shapes through formulas. Although it can read things like circles, cut circles etc., when it saves it, it re-writes it based on the equation of the shape. –Many elements of the specification can not be created using OpenOffice or KOffice  And so on...