ODF Workshop  ODF: The Past, Present and Future  Michael Brauer, Sun, ODF TC Chair  ODF Accessibility  Pete Brunet, IBM, ODF Accessibility Subcommittee  ODF Programmability  Rob Weir, IBM, ODF TC  Michael Brauer, Sun, ODF TC Chair  ODF Interoperability  Alan Clark, Novell, ODF Adoption TC  Rob Weir, IBM, ODF TC  ODF Adoption  Don Harbison, IBM, ODF Adoption TC Co-Chair OASIS OpenDocument ISO/IEC 26300 The Past, the Present, and the Future

Michael Brauer Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems About the Speaker  Technical Architect in Sun Microsystem's OpenOffice.org/StarOffice development  OpenOffice.org/StarOffice developer since 1995  Main focus: Office application development/file formats and XML technologies  OpenOffice.org XML project owner  OASIS OpenDocument Technical Committee chair Agenda  The Past - History of OASIS OpenDocument format  The Present – Sub Committees, Work in Progress  The Future – OpenDocument v1.2 The Past 1999 Development of “StarOffice XML” file format starts  Primary goal: interoperability 2000 Sun contributes StarOffice to OpenOffice.org  “StarOffice XML” becomes “OpenOffice.org XML” open source community project  First OpenOffice.org XML working draft publicly available 2001 OpenOffice.org XML is used as default file format for OpenOffice.org 1.0/Sun StarOffice 6.0 software 2002 Foundation of OASIS OpenDocument Technical Committee (TC)  Basis of TC's work: OpenOffice.org XML file format OpenDocument TC Charter (Extract)  The purpose [...] is to create an open, XML-based file format specification for office applications.  [it] must meet the following requirements:  it must be suitable for office documents containing text, , charts, and graphical documents,  it must retain high-level information suitable for editing the document,  it must be friendly to transformations using XSLT or similar XML-based languages or tools,  it should 'borrow' from similar, existing standards wherever possible and permitted. OpenDocument TC Charter (Summary)  Vendor independence  Interoperability  between office applications  between office applications and other solution  Simplicity for file format users  Solid basis for the future How OpenDocument Does It  Reuses standards  XHTML, SVG, SMIL, XSL, XForms, MathML, XLink and Dublin Core Meta Initiative  Reuses its own schema fragments  One paragraph schema, one table schema, one graphical object schema, etc.  Benefits  Easy to transform and learn  Expressive schema  Compact specification (only ~700 pages) The Past (Continued) 2004 Committee Drafts 1 and 2 publicly available 2005 Name change to “OASIS Open Document Format for Office Applications (OpenDocument)”  Previous name: OASIS Open Office XML TC  Emphasizes application and use case independence  Also called “ODF” 2005

 OpenDocument v1.0 gets approved as OASIS standard The Past (Continued) 2005 (OASIS) OpenDocument submitted to ISO Foundation Of Accessibility Sub Committee 2006 Foundation Of Formula Sub Committee Foundation Of Metadata Sub Committee Foundation of ODF Adoption TC OpenDocument v1.0 gets published as ISO/IEC 26300 The Present 2007 OpenDocument v1.1 gets approved as OASIS standard  Includes Enhancements for Accessibility OpenDocument v1.2 is worked on  Within the three SCs: Accessibility, Metadata, Formula  Within the main TC First OpenDocument v1.2 drafts get published The Accessibility Sub Committee  Purpose (extracted from charter)  To liaise with the disability community to gather accessibility related feedback on [...] OpenDocument v1.0  To gather [...] feedback from implementors  To produce a formal accessibility evaluation of the OpenDocument v1.0 file format.  SC membership includes many accessibility experts The Accessibility Evaluation  Completed May 2006  Lists 9 accessibility issues for ODF v1.0  If these are resolved, the SC believes that  OpenDocument will meet or exceed the accessibility support provided in all other office file formats  as well as that specified in the W3C Web Content Accessibility Guidelines 1.0.  Examples:  No alternative text for non-text image map elements  No alternative text for drawing objects  No clear relationships between drawing objects and their captions  No tables in presentations The Accessibility Sub Committee  Status  8 issues were resolved in ODF v1.1  1 issue will be resolved in ODF v1.2  “Table Shape” for presentations  An accessible workaround does exist for ODF v1.0/v1.1  SC agreed to continue its work after v1.1 was completed  Ongoing accessibility review of ODF v1.2, ...  Implementation guidelines are in progress The Formula Sub Committee (OpenFormula)  Purpose (extracted from charter)  To create a [standardized] specification for a formula language that should be used in OpenDocument documents [..]  Status  OpenFormula draft is available publicly  Specification is nearly complete and in the stabilization phase OpenDocument and OpenFormula  OpenDocument v1.0  Supports arbitrary spreadsheet formula languages  Identification through XML namespaces  Does not define its own formula language  Uses non-standardized but well-defined formula languages  OpenFormula  Will be a separate specification document  Is usable with OpenDocument v1.0 and v1.1  Will become OpenDocument v1.2's standardized and recommended formula language  Others formula languages remain usable  Example: formula languages tailored to customer use cases Metadata Sub Committee  Purpose (extracted from charter)  To gather use cases for the application of metadata in OpenDocument documents  To propose metadata related enhancements  What is Metadata?  Structured data about data, that  Describes, explains, locates, or otherwise makes it easier to retrieve, use, or manage an information resource  Typically used to describe documents, images, contacts, events, and so forth Metadata Sub Committee  Why is Metadata important?  Allows authors to encode his/her human intelligence into the documents  Enables powerful automated solutions  Standards based replacement for custom/user-defined XML markup within office documents  Status  Use case and Requirements document is available  First Proposal is available  Based on W3C RDF and W3C RDF/XML Metadata, Forms, Custom Schemas  Office versus Custom Schema  Office Schema: Schema/markup for office documents  Tailored to office documents, Feature complete  Custom Schema: Any other schema/markup interleaved with office schema  Standard schemas (UBL, etc.) or user defined schemas: Defined by customer (Bills, orders, etc.)  Used to store information not covered by office schema  Use cases for custom schemas  XML based data entry forms  Metadata Metadata, Forms, Custom Schemas  Custom schemas  Feature of XML and XML Namespaces  inherently supported by the OpenDocument  Only one of many solutions for forms/metadata  Data entry forms in OpenDocument  OpenDocument v1.0 supports W3C XForms  Clean separation of form instance and office markup  Standardized solution  Metadata in OpenDocument  Will be based on RDF  Standardized solution The Future  OpenDocument v1.2  Includes  A formula specification  A meta data specification  Many other enhancements that • Are new office application features • Improve interoperability with ECMA-376 (OOXML)  Will be reviewed by Accessibility SC  Aimed to be finished 2007  Planned to be re-submitted to ISO  ODF Accessibility Guidelines Questions & Answers OASIS OpenDocument ISO/IEC 26300 The Past, the Present, and the Future

Michael Brauer [email protected] OpenDocument Format - Accessibility

Pete Brunet Accessibility Software Engineer IBM Software Group

© 2007 IBM Corporation ODF Accessibility – Initial Problem  In Federal Government bids software must be accessible by Persons with Disabilities.  Section 508 – US Rehabilitation Act  Now becoming important for States, e.g.Commonwealth of Massachusetts  Also California, Texas, Minnesota  ODF Accessibility issues were highlighted by Microsoft lobbyists in Massachusetts.  Leaders from IBM worked with the ODF TC to form the Accessibility SC (see next slide).  OASIS ODF AccSC was formed and responded very quickly.

Committee Formed  IBM – Rich Schwerdtfeger (co-chair), Dr. Chieko Asakawa, Dr. Hiro Takagi, Pete Brunet  Sun – Peter Korn (co-chair), Malte Timmerman  Design Science – Steve Nobel  The Paciello Group – Mike Paciello  Capital Accessibility – Janina Sajka  Institute of Community Inclusion – David Clark  Royal National Institute for the Blind – Dave Pawson  New member: Duxbury Systems (Braille translators)

GAP Analysis  The Accessibility Subcommittee (AccSC) was formed in January 26, 2006.  A GAP analysis was conducted.  Comparison to W3C WCAG 1.0 and the Microsoft Office suite  Nine issues were identified and submitted to the TC during May 2006.

Influence of Notes 8  Spec effort helped by IBM's implementation of ODF into Notes 8 during 2006.  Additional issues were encountered and fixed in the spec, e.g. usage of table headers.  Both spec and implementation were improved due to development in parallel.

Nine Recommendations  Soft page breaks - for transformation to talking book formats, e.g. DAISY  Usage of table row/column headers clarified – important for orientation for users who are blind  Logical navigation order for presentation – keyboard navigation order was usually not correct  Alternative text for graphical objects, image maps, drawing layers and hyperlinks (4 recommendations) – descriptions needed by users who are blind  Association of captions to captioned content – helps screen readers find caption without guessing  Tables as first class presentation objects – helps navigation through tables by users who are blind Guidelines  A non-normative accessibility guideline provided in Appendix E  Title, Description and Caption of Graphical Elements  Hyperlink Titles  Tables in Presentations  A much larger guideline is being created for ODF 1.2

TC Approval  Eight of the nine issues were approved  Tables as first class presentation objects will be in ODF 1.2  1.1 workaround – embed as spreadsheet  ODF 1.1 announced February 13, 2007

Cross team collaboration resulted in an Accessible solution 1 File format enabled for accessibility ● ODF 1.1 – ODF AccSC team of accessibility experts 2 Guidelines for Doc Authors and App Developers ● ODF AccSC team 3 Transformation from ODF to accessibility API ● Notes 8 Development team – IBM China SW Dev Lab 4 Accessibility API to provide access to content  IAccessible2 – IBM Accessibilty Architecture team 5 Assistive Technology, e.g. Screen Readers using the standardized API  JAWS – Development team from Freedom Scientific  Window-Eyes – Development team from GWMicro Influence on Windows A11y  IAccessible2 exits due to need for access to ODF docs.  Adds features to complement MSAA.  Adds access to rich content provided by ODF docs (see next slide).  On Windows IAccessible2 will improve accessibility and usability for PwDs beyond ODF docs.  Examples: Firefox and Eclipse

IAccessibleTable  accessibleAt  rowIndex  caption  selectedRows  childIndex  selectedColumns  columnDescription  summary  columnExtentAt  isColumnSelected  columnHeader  isRowSelected  columnIndex  isSelected  nColumns  selectRow  nRows  selectColumn  nSelectedColumns  unselectRow  nSelectedRows  unselectColumn  rowDescription  rowColumnExtentsAtIndex  rowExtentAt  modelChange  rowHeader Office Suites  Microsoft Office is no longer the only solution.  ODF 1.1 enables access to documents based on open standards:  IBM Lotus Notes 8 Productivity Editors, Open Office, Sun Star Office, KDE KOffice  Notes 8 editors accessible from JAWS and Window- Eyes  Demo: JAWS with an IBM Lotus Document

9 Issues - Notes 8 Implementation 1. Soft page breaks  Notes 8 uses element and attribute

9 Issues - Notes 8 Implementation 2. Support table header structural markup  Notes 8 supports table row/column headers.  IAccessibleTable:RowHeader and IAccessibleTable::ColumnHeader provide accessible information

9 Issues - Notes 8 Implementation 3. Provide for author specified, logical navigation in presentations  Special dialog for logical navigation order.

9 Issues - Notes 8 Implementation 4. Alternative text for image map elements  Image map elements have (alt text) and (description).  IAccessibleHyperlink::description will display . If is null IAccessibleHyperlink::description will display the .

9 Issues - Notes 8 Implementation 5. Alternative Text for Drawing Layer

Alt text and long description fields added.

9 Issues - Notes 8 Implementation 6. Alternative Text for Drawing Objects  Text fields for alternative text & long description.  Exposed via MSAA's name and description.

9 Issues - Notes 8 Implementation 7. Relations between Objects & Captions  Relation is exposed via ODF  And via the IAccessible2 describedBy relation.

9 Issues - Notes 8 Implementation 8. Establish text hints for hyperlinks

Object 1

The description is saved to and is exposed by IAccessibleHyperlink:description.

9 Issues - Notes 8 Implementation 9. Tables in Presentations  Work-around for ODF 1.1  Encoded as embedded spreadsheet  To be encoded as table:table in ODF 1.2

Fostering Innovation - DAISY  ODF 1.1 based docs can be used as content for DAISY talking books.  Dave Pawson from RNIB is an XML and XSLT expert and he made very significant contributions to the spec.  Soft page breaks were added to ODF 1.1  ODF 1.1 content is being transformed into DAISY content.  Open standards developed by industry experts facilitate innovation.

Fostering Innovation - Duxbury  Duxbury Systems  Tooling to create Braille content  Compared to Word 2003 Duxbury gives ODF higher marks in the area of documentation, simplicity -- and reusability:  ODF importer shares code in common with importers for OpenXML, HTML, DAISY/NIMAS, and generic "XML".  ODF allowed re-use of table importer between word processing and spreadsheet editors  This ease of reuse lowers the price barrier for creating Braille content.

Duxbury - ODF to Braille  Unpack content.  Preprocess  Resolve issues that cause XML parsing problems  Transform with XSLT (od.xsl)  “Pick out” the parts of interest  Omit extraneous items  Set up “hints” for post-processing  Map styles in XML (xsmod.xml)  Allows application to different document standards  Postprocess  Re-encode characters  Eliminate most empty nodes  Transform “hints” to direct DBT codes  Pack .dxp Fostering Innovation - Validation ODF validation – more innovation  UIUC - Illinois Center for Information Technology Accessibility  Web based accessibility checker  http://odf.cita.uiuc.edu/  IBM's Tokyo Research Lab  aDesigner  Demo

ODF Programmability – What we need & What we have

Robert Weir Software Architect IBM Software Group [email protected] http://www.robweir.com/blog

© 2007 IBM Corporation What we had before  DOC/XLS/PPT  Proprietary binary formats  Documentation incomplete and outdated  An opaque format distorts application development  Leads to “inside out” style  Put code in the document  Tied to Windows  Tied to client  Hard to manage  Vector for viruses  Code doesn't live where the documents live The potential  ODF – a platform and application neutral office file format  Document data is no longer trapped in proprietary black box binaries  Transparent format fosters external manipulation of documents  This can lead to a “golden age” of document processing, both client and server side, with much innovation

 “We have it in our power to create the world over again” -- Thomas Paine More than just editors (20 Prototypical Scenarios)

1.Interactive creation in an a heavy-weight client application 2.Interactive creation in a light-weight web-based application 3.Collaborative (multi-author) editing 4.Automatic creation in response to a database query (report generation) 5.Indexing/scanning of document for search

20 Prototypical App Dev Scenarios 6.Scanning by anti-virus 7.Other types of scanning, perhaps for regulatory compliance, legal or forensic purposes 8.Validation of document, to specifications, house style guidelines, accessibility best practices, etc. 9.Read-only display of document on machine without the full editor (viewer) 10.Conversion of document from one editable format to another

20 Prototypical App Dev Scenarios 11.Conversion of document into a presentation format, such as PDF, PS, print or fax 12.Rendering of document via other modes such as sound or video (DAISY Talking Book) 13.Reduction/simplification of document to render on a sub- desktop device such as cell phone or PDA. 14.Import of data from an office document into a non-office application, i.e., import of spreadsheet data into statistical analysis software. 15.Export of data from a non-office application into an office format, such as an export of a spreadsheet from a personal finance application.

20 Prototypical App Dev Scenarios 16.Application which takes an existing document and outputs a modified version of that presentation, e.g., fills out a template, translates the language, etc. 17.Software which adds or verifies digital signatures on a document in order to control access (DRM) 18.Software which uses documents in part of a workflow, but treats the document as a black box, or perhaps is aware of only basic metadata. 19.Software which treats documents as part of a workflow, but is able to introspect the document and make decisions based on the content. 20.Software which packs/unpacks a document into relational database form.

The Problem

 700+ page ODF Specification

 No objections to it as a specification – it is what it needs to be

 Written from the perspective of word processor implementors

 Too much to ask the average app developer to master

Analogy with XML -- Who actually reads this stuff?

What is really used is SAX

And DOM

The Challenge

We need an ODF API that exposes a higher level abstraction of ODF to application developers, so they can quickly become productive with ODF processing without having to master a 700 page specification

“Create a loan amortization spreadsheet in 30 lines of code”

Odfpy

Low Level, close to the XML Maps validity errors into runtime exceptions. Odfpy

odf4j

Part of OpenOffice.org Toolkit project. Still early.

AODL

An Open Document Library – C# Library

OpenOffice::OODoc

The Perl Open OpenDocument Connector.

Relatively complete and established.

Toolkits I've Looked At

Name Language WP SS Pres URL Odfpy Python X X X http://opendocumentfellowship.org/projects/odfpy OooPy Python http://ooopy.sourceforge.net/ OpenDocumentPHP PHP X X http://opendocumentphp.org/ AODL C# X X http://opendocument4all.com/content/view/13/29/ OpenOffice::OOCBuilder Perl X http://search.cpan.org/dist/OpenOffice-OOBuilder/OOCBuilder.pm PyOpenOffice Python X http://www.bezirksreiter.de/PyOpenOffice.htm Odf4j Java X X X http://odftoolkit.openoffice.org/source/browse/odftoolkit/odf4j/ OpenOffice::OODOC Perl X X http://search.cpan.org/dist/OpenOffice-OODoc/

Some demos from J. David

Book available online at: http://books.evc-cit.info or in printed form from: http://www.lulu.com/content/207835

Proceeds to benefit the OpenDocument Fellowship

The OpenOffice.org ODF Toolkit Project

Michael Brauer Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems Agenda  Overview  What is an ODF Toolkit?  What is the OpenOffice.org ODF Toolkit Project  OpenOffice.org ODF Toolkit  Explained  Relation between the ODF Toolkit an OpenOffice.org  Project Status ODF Toolkit – A New OOo Project What is an ODF Toolkit?  An ODF Toolkit is a programming framework, that:  Allows the creation/manipulation of ODF documents  Runs outside traditional office application  Is lightweight (compared to office applications)  Has APIs tailored to ODF  Enables a common basis for ODF solutions What is an ODF Toolkit?  An ODF Toolkit is supplemented by:  ODF Document Viewers  ODF Document Printers  ODF Authoring Tools  Etc.  Sometimes called “ODF Universe”  Supplemental Tools may use ODF Toolkit as basis Use Cases  Automatic and Semi-Automatic document creation  Collaboration Tools  Document Converters from/to ODF  Workflow Modelling  Many more The OOo ODF Toolkit Project  Purpose 1: To improve the ability to use OOo as programming framework by:  Extracting an appropriate, document-centric subset from the OOo source code (Modularization, Re-Packaging)  no UI, no controllers, etc.  Adapting the subset to the new purpose  New and adapted APIs  New (sub-)components  Making the OOo desktop application a client of the toolkit The OOo ODF Toolkit Project  Purpose 2: To provide a home for components that:  Are ODF related, and  Complement the ODF Toolkit, or  Are clients of the ODF Toolkit The OOo ODF Toolkit Project  Samples:  Transformations into other formats, e.g. XHTML.  “Adapters” that add ODF support to other tools and products, for instance content management systems.  API Snippets for re-occurring ODF related tasks. ODF Toolkit – The Pieces ODF Toolkit – The Pieces ODF Toolkit – The Pieces ODF Toolkit – The Pieces ODF Toolkit – The Pieces ODF Toolkit – The Pieces Why (re-)using OOo?  OpenOffice.org provides much of the functionality that is required  Should be made available to other implementations  OOo has proven its usefulness  Many projects use OpenOffice.org already  Complain is not functionality, but size Why (re-)using OOo?  OOo has a programming-language neutral API  Based on UNO component model (Universal Network Objects)  Supports Java, C++, and others  Uno Runtime Environment (URE) is available separately  Many solutions use OpenOffice.org for related functionality:  Authoring, Printing, Viewing, Conversion Services, etc. Why is it an OOo Project?  Fosters synergies between desktop application and programming environment  Fosters harmonization of APIs  Fosters interoperability of ODF components  Fosters code re-use  OOo has 6,000,000 lines of code!  Simplifies use of ODF Toolkit  Harmonized API, Licence  One source of information Where are we?  Launched in January 2007  Modularization/Re-Packaging:  First Proof-Of-Concept Prototype is existing  Separation of URE/office core/branding is in progress Where are we?  New Components:  .NET Module “AODL” (implemented in C#)  ODF package handing,  Access to ODF XML structures  Basic ODF document API  Odf4j Module (Java)  ODF package handing,  Access to ODF XML structures (DOM, XSLT)  Basic standalone document processing  More to come More Information  odftoolkit.openoffice.org  blogs.sun.com/GullFOSS Questions & Answers The OpenOffice.org ODF Toolkit Project

Michael Brauer [email protected] ODF – A discussion on interoperability

Alan Clark Strategic Adviser for Industry Initiatives and Standards [email protected]

Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of features or functionality described for Novell products remains at the sole discretion of Novell. Marooned by time “Perhaps the most immediate problem is the speed of technological change, which leaves data in old formats marooned by time. “ “In January of this year [2007], floppy discs were added to the crowded computer cemetery” “This...could happen to documents we're writing in 2007,... It's not in some software companies' interests to preserve because the want to sell products year after year. We take it for granted that these companies will still be around – but all companies fold; who will take on the responsibility for maintaining and updating the software after that?” Financial Times, March 17, 2007 [1]

What is Open Document Format (ODF)  An XML- based specification describing the content and formatting of a document.  The developed by a multi- vendor committee at OASIS and approved by ISO.  The standard that meets the common test for openness  The default format in OpenOffice.org, StarOffice, KOffice, and IBM Productivity Tools  The open standard adopted and supported by many vendors.  The option that gives you the most choices for interoperability and future- proofing the access to your information.

Enabling New Concepts

Online / Browser

Offline / PC

Benefits

• Long-term reuse of and access to data • No lock-in to proprietary tools or undocumented formats • Competitive data processing products • Reduced costs • Increased reliability, because more data automation • Platform independence • Interoperability

Interoperability  "With respect to software, the term interoperability is used to describe the capability of different programs to exchange data via a common set of business procedures, and to read and write the same file formats and use the same protocols." [2]  “Interoperability contends with the software- and implementation details of interoperations, including exchange of data elements based on a common data interpretation, etc.” [3]

Levels of interoperability Level Factors and Perspectives Component behavior 4 Enterprise Shared data and applications visible to the integrator Common ontology, Shared data separate common reference 3 Domain applications model Minimal common functions. Separate data and Exchange of annotated 2 Functional applications imagery, Http... Electronic connection. Ability Text file transfers, to establish mapping layers to Telnet, FTP, E-mail 1 Connected interconnect chatter Interoperability Isolated, Hard coded data, Comma 0 Isolated Non-connected separated lists

Measuring interoperability  Describes multiple, independent descriptions of different facets of integration  Weighted by individual perspective  Typically results in  Uncovering issues  Developing best practices  Better standards

What is the state of interoperability with ODF today?

 The number of products and technologies utilizing ODF is rapidly growing  The number of consumers (aka market acceptance) is exponentially growing  The completeness and degree of interoperability between products and technologies varies

Applications Supporting ODF

Multiple Office Suites – One Format

Why Interop. is so important ....Plug-ins and Translators  OO.o Market share  http://wiki.services.openoffice.org/wiki/Market_Share_Analysis  Main site downloads: 80million, + Spanish/India x2 -> 8.5million  Oct 05 – Yankee Group: 19% of SME ... Current Market Share (best-case)  Microsoft Market share:  400 million Office users worldwide  1.1bn Internet Users (Global Reach) MSO OOo  Good news ...  But Document share is different:  ODF is -very- new, .DOC is -very- old ... Assuming legacy doc tail  There are a huge number of documents out there

DOC ODF

Translators / Converters  OpenXML Translator (ODF Add-in for Word)  An Add-in to Microsoft Word (XP, 2003, & 2007) to allow opening and saving OpenDocument format (ODF) files.  Also provide a command line translator for batch conversions. • http://download.novell.com/SummaryFree.jsp?buildid=ESrjfdE4U58~  StarOffice 8 MS Office 3 conversion plug-in  Initial plug-in application to support the conversion of text documents (.doc/.odt).  Full support for spreadsheet and presentations is expected by April  ODF and Chinese Document Format (UOF)  http://odf-to-uof.sourceforge.net/index.html

ODF Viewers  View an ODF text file, spreadsheet or presentation  Viewers support the features that you would expect  Retains proper formating and document characteristics • Standard viewing features: paged view, print preview and changing the text size. • Standard navigation features like search  Smaller footprint  Fully uses display, document is “flowable” on the screen  Valuable ODF Properties compared to other formats  Small (compressed files)  Editable  Fully open international standard  Supports international documents  Document properties like word count etc.  For developers: View ODF source.

ODF on the Web  Browser extensions to view ODF Documents directly

 If you are using Wiki's an extension is a life saver  A user states, “Oh the hours I've wasted waiting for ooo to open just to quickly look something up in a file! No more, it is so much faster to view them in firefox.”

 ODF to HTML conversion tools  Typically limited to what can be represented in HTML but are fast and capable

Mobile device support  ODF Documents on mobile devices  Read files on the road  Mobile access with document viewing accuracy increases productivity  Facilitates searching, printing, sharing, faxing, presenting  Support for OpenDocument text(.odt), spreadsheet(.ods) and presentation(.odp)  Nearly 30 percent of all emails contain attachments.  ODF support eliminates the need to convert attachments to other formats  Renders representation of the files without needing to load a full office suite • Enables file viewing, printing, and copy/paste functionality 

Integration with the desktop  Desktop search tools

 Indexes and searches multiple file formats including ODF  Beagle  Google Desktop Search  Copernic  OpenIndexer  Xapian's Omega  Windows Desktop Search  NeoOffice

Developer Kits  PHP, Python, Javascript, C#, C and Other developer kits  ODF functionality ranges from extensive down to being “redesigned”  Kits include:  The OpenOffice.org ODF Toolkit Project  Perl OpenDocument Connector  AODL – An Open Document Library  OpenDocumentPHP  ODFPY - Python API and tools  ...

Additional Tools  Computer-assisted Language Translation  http://en.wikipedia.org/wiki/OmegaT  Document Management Systems and Repositories  GTLScube  DROID  Document cleaning  3BClean: http://www.3bview.com/3bclean.html  Accessibility Evaluator  http://odf.cita.uiuc.edu/  Weblog Publisher

Summary  ODF is the root of bigger changes  Interoperability discussions are a good thing  Think about interoperability in terms of:  longetivity  Broad application support

References  [1] Financial Times, March 17, 2007, “Where will history end up?”, Rob Blackhurst  [2] http://www.sisostds.org/index.php?tg=fileman&idx=get&id=2&gr=Y&path=Simulation+Interope rability+Workshops%2F2003+Fall+SIW%2F2003+Fall+SIW+Papers+and+Presentations&file= 03F-SIW-007.pdf  [3] Tolk, A. and Muguira, J.A. (2003). The Levels of Conceptual Interoperability Model (LCIM). Proceedings IEEE Fall Simulation Interoperability Workshop, IEEE CS Press  [4] Wikipedia: http://en.wikipedia.org/wiki/OpenDocument  [5] http://www.digitalpreservation.gov/formats/sustain/sustain.shtml

ODF Interoperability – The Price of Success

Robert Weir Software Architect IBM Software Group [email protected] http://www.robweir.com/blog

© 2007 IBM Corporation Many ODF Implementations OpenOffice KOffice AbiWord

Notes 8

SEPT Mobile Office Google Docs

MS Office With N editors, there are N*(N-1) interoperability tests Things that cause problems  Application issues  Implementation defects  Functional subsets  Functional supersets

 Standard issues  Specification errors  Undefined behaviors  Implementation-defined behaviors

Solution Patterns  Standards-development  Multi-vendor participation  Expert review  Implementation concurrent with standards development  Standards  Conformance clauses  Deep schemas, allowing deep validation  Reference implementations  Post standardization activities  Translation  Conformance assessment/certification  Multiple implementations

A powerful pattern

Standard Test Suite

Reference Implementation

A powerful pattern  The standard contains the definition of a conformant document  It may have errors or ambiguities  The test suite exercises and validates each feature of the standard  It may have errors, including omissions  The reference implementation is written to the standard, and tested with the test suite  It may have errors, including missing functionality

Checks and Balances  A test case fails. What is the cause?  An error in the application?  Is it an error in the test suite?  An error in the standard?  Identify the cause of the failure  Fix  Repeat  Continue until you have a complete test suite and a reference implementation that passes all of the test cases.

A rough estimate  ~ 700 page ODF specification  ~ 5 testable statements per page  ~ 4 test cases per statement to test limits, positive and negative test cases, etc.

 So, on the order of 14,000 test cases

This can help move us from... OpenOffice KOffice AbiWord

Notes 8

SEPT Mobile Office Google Docs

MS Office With N editors, there are N*(N-1) interoperability tests ...to this KOffice

OpenOffice AbiWord

Conformance Notes 8 Assessment

SEPT Mobile Office Google Docs MS Office

With N editors, there are N conformance assessments Progress in Interoperability  Test Suites  Validators  Translators

ODF Test Suite

http://develop.opendocumentfellowship.org/testsuite/ ODF Validator

http://opendocumentfellowship.org/validator ODF Add-in for Word

http://odf-converter.sourceforge.net/

ODF Plug-in for MS Office

http://www.sun.com/software/star/openoffice/