OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odf-adoption message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [odf-adoption] conformance


Hi Gary,

Thanks a lot for the great write-up! This information is very useful!
You provide a very detailed overview about the technical aspects of
conformance. Unfortunately, I'm not sure how to best deal with this
conformance "beast", i.e. what the best next steps are.

Another way (but obviously a very closely related one) of approaching
the conformance problem is by looking at the list of already available
applications which offer some level of ODF support:

http://en.wikipedia.org/wiki/List_of_applications_supporting_OpenDocument

Looking at the list it seems like office productivity applications
are most advanced with respect to ODF support. In addition, we seem
to have a draft test suite for testing ODF formatting and content:

http://netmoc.cpe.ucf.edu/Projects/OpenDocument/TestSuite.html

Thus, as one possible next step we could encourage the vendors of
the ODF applications to run the test cases and to provide screenshots
of the results. Maybe a community of volunteers could help with
that effort. In parallel, both the vendors and the "ODF QA community"
could help the creators of the test suite to improve their work.

Since layout information is difficult to meassure, I'm not sure
if and how we could say if an application completed a specific test
case successfully or not, but I guess that issue could be solved
somehow.

Such an effort would not address the whole spectrum of conformance.
In addition, we would not immediately have a complete "conformance
program". However, we would gradually help ISV's and open source
communities to increase the level of ODF compatibility between
different ODF implementations from an office productivity and end
user point of view.

For publicity purposes we could do something like the Deployathons
that were done in the Java technology space:

http://java.sun.com/developer/technicalArticles/Programming/deployathon/
http://java.sun.com/developer/technicalArticles/J2EE/deployathon2/

Thus, we would show case the ODF compatibility of different ODF
implementations by opening and editing different complex ODF
documents.

As I said, such an approach would not immediately lead to a
logo program, but it could be a good first step.

For other domains like document search or document management
we could do something similar by leveraging the meta data
information. But first I think we should try to "recruit" a
few more CMS/DMS ISV's.

BTW, most likely Waldo Bastian will join our next Adoption
TC meeting in order to tell us a bit more about the test
suite that he has been involved in.


Best regards,
Erwin



Gary Edwards wrote:
> 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 
> <http://www.tbray.org/ongoing/When/200x/2006/01/09/On-XML-Language-Design> 
> · If you’re going to be designing a new XML language, first of all, 
> consider not doing it 
> <http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages>. 
> 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 ... 
> <http://www.tbray.org/ongoing/When/200x/2006/01/09/On-XML-Language-Design>
> 
> 
> Don’t Invent XML Languages 
> <http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-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.
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]