Hi Adoption TC,
At the Monday ODF TC conference call we
discussed the issues of conformance, compliance and
interoperability. What follows are my notes on that
discussion. Patrick Durusau also asked that the Adoption TC
review Section 1.5 of the ODF standard which concerns "conformance".
He pointed out that this specific wording is included in the OASIS
ratified version of the ODF spec, the one that is about to become an
ISO standard. (Meaning there is no chance of changing this
wording until probably December of 2006 - which is the earliest date
under discussion for the release of ODF 2.0). Patrick is
one of the ODF TC founding members, chairman of the ODF Metadata
SubC, and, co chairman of the ISO JTCS1 where he also serves as
"editor" of the ODF spec.
The relevant sections from
the ODF Spec Section 1.5 follow:
********************************
-
Documents
that conform to the OpenDocument specification /may/ contain
elements and attributes not specified within the OpenDocument schema.
Such elements and attributes must not be part of a namespace that is
defined within this specification and are called foreign elements and
attributes.
-
Conforming applications either /must/ read
documents that are valid
against the OpenDocument schema if all foreign elements and attributes
are removed before validation takes place, or /must/ write documents
that are valid against the OpenDocument schema if all foreign elements
and attributes are removed before validation takes place.
-
Conforming applications that read and
write documents /may/ preserve
foreign elements and attributes.
In addition to this, conforming applications should preserve meta
information and the content of styles. This means:
* The various |<style:*-properties>| elements (see section 15)
/may/
have arbitrary attributes attached and /may/ have arbitrary
element content. All attributes attached to these elements and
elements contained within these elements /should/ be preserved
(see section 15.1.3);
* elements contained within the |<office:meta>| element /may/
have
arbitrary element content and /should/ be preserved (see section
2.2.1).
Foreign elements /may/ have an |office:process-content| attribute
attached that has the value |true| or |false|. If the attribute's value
is |true|, or if the attribute does not exist, the element's content
/should/ be processed by conforming applications. Otherwise conforming
applications /should not/ process the element's content, but /may/ only
preserve its content. If the element's content should be processed, the
document itself /must/ be valid against the OpenDocument schema if the
unknown element is replaced with its content only.
Conforming applications /must/ read documents containing processing
instructions and /should/ preserve them.
There are no rules regarding the elements and attributes that actually
have to be supported by conforming applications, except that
applications should not use foreign elements and attributes for features
by the OpenDocument schema. See also appendix D.
***************************
I came away from the Monday ODF TC
discussion with four conformance
aspects to consider:
Application or Implementation:
There are now Office productivity suites, single purpose
applications (spreadsheets, word processors), and web based software
services using ODF Java Classes and Libraries. Some are fully
ODF read/write compatible, others just read or write, and still
others are pure transformation - even roundtrip. And then there
are the AJAX - XUL ODF (Writely, Zimbra, and ajaxWriter) components
that are showing up all over the place.
Layer:
Exampled by conformance at the Metadata layer, where different
file formats such as PDF, PDF Forms, Lotus Notes, ODF, and even
MSECMAXML would become usefully interoperable because they share the
same metadata model.
Schema:
This is
an area where vertical industries and shared business processes
implement ODF as a baseline, seeking to build semantic and ontology
specific extensions above the baseline. LegalXML, Health Care,
Real Estate, Finance, Insurance are just a few of the examples of
what really is a universal shift from a software bound client/server
database driven interface model to one where the self described,
semantic rich document becomes the primary interface to information
and information systems. Once again the metadata XML::RDF
model rises to the forefront as the best way of getting this done.
Structure:
This would be conformance at the XML
eXtension (or dependency) level within ODF - such as XHTML, SVG,
SMiL, XSLT, and XForms.
Interoperability:
Another angle that might help us in our effort to come to grips
with the conformance issue is that of interoperability, especially as
it applies to a specific layer. For instance, the work of the
three ODF TC SubC's could be considered layers where interoperability
with other file formats could be greatly enhanced. The 3 SubC's
are: Accessibility, Formula and Metadata.
The reason i
refer to these extensions/enhancements of the spec as "layers"
is that it's possible for other non XML file formats or
platform/system bound XML file formats to comply with the ODF
implementation without significantly altering the file format
itself. PDF and PDF Forms could be a good example of this layer
of compatibility; achieved through a transparent interoperability
between the Adobe XMP XML::RDF metadata model and the emerging ODF
XML::RDF metadata model.
It's also conceivable that
many applications might embrace the entire ODF implementation feature
set of Accessibility, Formula, and Metadata, and use them across many
different file format structures, but not conform in any other way
with ODF. The result isn't ODF, but there would no doubt be a
great deal of interoperability made possible if the enhancements are
exposed so a common set of tools could be used to work against a
content store of mixed file formats.
I also asked this
question of ODF Metadata SubC Chair Patrick Durusau: If XHTML 2.0 and
ODF share the same metadata model, (which is very likely), and you
have valid transformation from XHTML to ODF (but perhaps not from ODF
to XHTML) is that enough "conformance" to make XHTML an ODF
compliant implementation?
Testing and Assistance:
When
the ODF TC took up the conformance testing suite issue, a little over
a year ago, there was consensus that we didn't want to "test"
as much as we wanted to "assist". Certainly we didn't
want a barrier to individuals, OSS communities, developers and
vendors desiring to work with the ODF ecosystem. Nor could we
guess at the width and breath of what working with ODF might mean.
A year ago it meant working within the context of desktop
productivity applications (word processors, spreadsheets,
presentation, and drawing programs with plans for contact - project -
workflow management apps). Since then we've seen an ODF ready
collaboration layer evolve that includes wiki's, blogs, web eMail and
web document - content management systems.
Identify
Problems and Difficulties - Provide Assistance and Advice:
The
testing suite we discussed back then was to be one where the ODF
ecosystem could be galvanized to identify signal to noise ratio type
problems where advice and assistance could be provided in ways that
implementers and providers were able to achieve their ODF related
goals. Meaning, they could actually deliver what they claimed
to be delivering. Whatever that might be. The TC
recognized that we if we tried to pre determine and measure through
our "testing" what those deliverables were, we ran the risk
of inadvertently crippling ODF innovation.
There are four
primary information domains where ODF is emerging as an important
consideration, and i think we ought to keep these four in mind as we
proceed with our compliance work:
-
Desktop productivity environment
-
Publication, content and archive
management systems
-
SOA ...... Service Oriented
Architectures
-
The Open Internet
The
opportunities for ODF within these four domains are really a
reflection of how important XML is becoming, and the incredible
levels of high fidelity interoperability and collaborative computing
made possible by XML techniques and methods. A few months ago
XML 1.0 co author Tim Bray posted two commentaries that i had hoped
would bring some sense to the sprawl of often conflicting and non
interoperable XML languages and schema's:
On
XML Language Design · If you’re
going to be designing a new XML language, first of all, consider
not doing it. But if you really have to, this piece discusses the
problems you’re apt to face and offers some advice on improving
your chances of success ...
Don’t
Invent XML Languages · The X in XML stands for
“Extensible”; one big selling point is that you can invent your
own XML languages to help you solve your own problems. But I’ve
become convinced, over the last couple of years, that you shouldn’t.
Unless you really have to. This piece explains why.
Here’s a radical idea: don’t even think of making your own
language until you’re sure that you can’t do the job using one of
the Big Five: XHTML, DocBook, ODF, UBL, and Atom.
ODF Baseline: This
brings me to the final discussion point, ODF as a Baseline on which
to build industry, disciplinary and business process specific
eXtensions. Examples would be LegalXML, Health Care,
Biomedical Research, Real Estate, Finance, Insurance, etc.
These industry verticals and disciplines have specific ontologies
that describe a shared process and, a shared XML schema design
enabling common document interoperability with disparate back end
databases and content management systems. With ODF as a
baseline, we would be assured of highly interoperable "cross"
industry - discipline - collaborative process layer. There
would also be the added developer - vendor benefit of a common syntax
and tooling system applicable across a greatly expanded ODF
ecosystem.
An important aspect of XML::RDF metadata model and
the future of ODF portability and usefulness is that of being self
describing document with a baseline implementation free from software
or system based dependencies, descriptions, and/or "expertise".
Above the baseline i think we should expect and even welcome
eXtensions of all sorts - even those with software and systems
specific dependencies. It's most important though that the
fidelity and portability of the baseline must be preserved and
gradually eXtended as part of the Open Standards process - separate
from the wide ranging "implementation" processes.
Will our conformance definition, description and testing
methodology be able to find and ride that ever evolving line
separating ODF baseline from higher level eXtensions certain to fork
or otherwise compromise the interoperability of a specific ODF
implementation?
I hope these notes contribute to the
conformance discussion, and i don't come off as a hand wringer
overwhelmed by the challenge. For sure there is lots to
consider here. What i would like to shoot for though is a
conformance approach designed to dramatically grow the ODF ecosystem,
and grow it way beyond what we can envision today.
~ge~
--
Gary Edwards
The OpenDocument Foundation, Inc.
Redwood
City, CA USA 94063
(650) 365-0899
(650) 888-2268
c.
gary.edwards@OpenDocument.us
http://OpendocumentFoundation.us
Founding
member of the OASIS OpenDocument TC, representing the OpenOffice.org
Community
Founding member of the OpenDocument
Foundation, Inc. - a USA 501c(3) non profit chartered in the public
interest to support, develop and promote the OASIS OpenDocument XML
file format.