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
ODF Workshop
OASIS OpenDocumentISO/IEC 26300The Past, the Present, and the FutureMichael BrauerTechnical Architect Software EngineeringStarOffice/OpenOffice.orgSun Microsystems
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
About the Speaker
The Past - History of OASIS OpenDocument format The Present – Sub Committees, Work in Progress The Future – OpenDocument v1.2
Agenda
The PastDevelopment of “StarOffice XML” file format starts
Primary goal: interoperabilitySun contributes StarOffice to OpenOffice.org
“StarOffice XML” becomes “OpenOffice.org XML” open source community project First OpenOffice.org XML working draft publicly available
OpenOffice.org XML is used as default file format for OpenOffice.org 1.0/Sun StarOffice 6.0 softwareFoundation of OASIS OpenDocument Technical Committee (TC)
Basis of TC's work: OpenOffice.org XML file format
1999
2000
2001
2002
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, spreadsheets, 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)Committee Drafts 1 and 2 publicly availableName 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”
OpenDocument v1.0 gets approved as OASIS standard
20042005
2005
The Past (Continued)(OASIS) OpenDocument submitted to ISOFoundation Of Accessibility Sub Committee Foundation Of Formula Sub Committee Foundation Of Metadata Sub Committee Foundation of ODF Adoption TCOpenDocument v1.0 gets published as ISO/IEC 26300
2005
2006
The PresentOpenDocument v1.1 gets approved as OASIS standard
Includes Enhancements for AccessibilityOpenDocument v1.2 is worked on
Within the three SCs: Accessibility, Metadata, Formula
Within the main TCFirst OpenDocument v1.2 drafts get published
2007
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 spreadsheet 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 OpenDocumentISO/IEC 26300The Past, the Present, and the FutureMichael [email protected]
© 2007 IBM Corporation
OpenDocument Format - Accessibility
Pete BrunetAccessibility Software EngineerIBM Software Group
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 solution1 File format enabled for accessibility
● ODF 1.1 – ODF AccSC team of accessibility experts2 Guidelines for Doc Authors and App Developers
● ODF AccSC team3 Transformation from ODF to accessibility API
● Notes 8 Development team – IBM China SW Dev Lab4 Accessibility API to provide access to content
IAccessible2 – IBM Accessibilty Architecture team5 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 caption childIndex columnDescription columnExtentAt columnHeader columnIndex nColumns nRows nSelectedColumns nSelectedRows rowDescription rowExtentAt rowHeader
rowIndex selectedRows selectedColumns summary isColumnSelected isRowSelected isSelected selectRow selectColumn unselectRow unselectColumn rowColumnExtentsAtIndex modelChange
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 Implementation1. Soft page breaks Notes 8 uses <text:soft-page-break> element and <text:use-
soft-page-breaks> attribute
9 Issues - Notes 8 Implementation2. Support table header structural markup Notes 8 supports table row/column headers. IAccessibleTable:RowHeader and
IAccessibleTable::ColumnHeader provide accessible information
9 Issues - Notes 8 Implementation3. Provide for author specified, logical navigation in
presentations Special dialog for logical navigation order.
9 Issues - Notes 8 Implementation4. Alternative text for image map elements Image map elements have <svg:title> (alt text) and
<svg:desc> (description). IAccessibleHyperlink::description will display <svg:title>. If
<svg:title> is null IAccessibleHyperlink::description will display the <svg:desc>.
9 Issues - Notes 8 Implementation5. Alternative Text for Drawing Layer
Alt text and long description fields added.
9 Issues - Notes 8 Implementation6. Alternative Text for Drawing Objects Text fields for alternative text & long description. Exposed via MSAA's name and description.
9 Issues - Notes 8 Implementation7. Relations between Objects & Captions Relation is exposed via ODF <draw:caption-id> And via the IAccessible2 describedBy relation.
9 Issues - Notes 8 Implementation8. Establish text hints for hyperlinks
The description is saved to <svg:title> and is exposed by IAccessibleHyperlink:description.
Object 1
9 Issues - Notes 8 Implementation9. 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.xml 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 <filename>.dxp
Fostering Innovation - ValidationODF 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
© 2007 IBM Corporation
ODF Programmability –What we need & What we have
Robert WeirSoftware ArchitectIBM Software [email protected]://www.robweir.com/blog
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) editing4.Automatic creation in response to a database query (report generation)
5.Indexing/scanning of document for search
20 PrototypicalApp Dev Scenarios
6.Scanning by anti-virus7.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 XMLMaps validity errors into runtime exceptions.
Odfpy
odf4j
Part of OpenOffice.org Toolkit project. Still early.
AODL
An Open Document Library – C# Library
OpenOffice::OODocThe Perl Open OpenDocument Connector.
Relatively complete and established.
Toolkits I've Looked At
Name Language WP SS Pres URLPython X X XPythonPHP X X
AODL C# X XPerl XPython X
Odf4j Java X X XOpenOffice::OODOC Perl X X
Odfpy http://opendocumentfellowship.org/projects/odfpyOooPy http://ooopy.sourceforge.net/OpenDocumentPHP http://opendocumentphp.org/
http://opendocument4all.com/content/view/13/29/OpenOffice::OOCBuilder http://search.cpan.org/dist/OpenOffice-OOBuilder/OOCBuilder.pmPyOpenOffice http://www.bezirksreiter.de/PyOpenOffice.htm
http://odftoolkit.openoffice.org/source/browse/odftoolkit/odf4j/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 ProjectMichael BrauerTechnical Architect Software EngineeringStarOffice/OpenOffice.orgSun Microsystems
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
Agenda
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 ProjectMichael [email protected]
Safe Harbor StatementThe 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.
ODF – A discussion on interoperability
Alan ClarkStrategic Adviser for Industry Initiatives and [email protected]
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 open standard 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
Offline / PC
Online / Browser
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 interoperabilityLevel Factors and Perspectives
4 Enterprise Shared data and applications
3 Domain
2 Functional
1 Connected
0 Isolated Non-connected
Component behavior visible to the integrator
Shared data separate applications
Common ontology, common reference
modelMinimal common functions.
Separate data and applications
Exchange of annotated imagery, Http...
Electronic connection. Ability to establish mapping layers to
interconnect
Text file transfers, Telnet, FTP, E-mail
chatterIsolated, Hard coded
data, Comma separated lists
Inte
rope
rabi
lity
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 ...
Microsoft Market share: 400 million Office users worldwide 1.1bn Internet Users (Global Reach)
Good news ... But Document share is different:
ODF is -very- new, .DOC is -very- old ... There are a huge number of documents out there
Current Market Share (best-case)
MSOOOo
Assuming legacy doc tail
DOCODF
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+Interoperability+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
© 2007 IBM Corporation
ODF Interoperability –The Price of Success
Robert WeirSoftware ArchitectIBM Software [email protected]://www.robweir.com/blog
Many ODF ImplementationsOpenOffice
Google Docs
KOffice
AbiWord
MS Office
Notes 8
SEPT Mobile 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
Reference Implementation
Test Suite
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
Google Docs
KOffice
AbiWord
MS Office
Notes 8
SEPT Mobile Office
With N editors, there are N*(N-1) interoperability tests
...to this
OpenOffice
Google Docs
KOffice
AbiWord
MS Office
Notes 8
SEPT Mobile Office
ConformanceAssessment
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/