tools for document interoperability
This is the web diary for nfoWorks and realization of the Harmony Principles. Pursuing Harmony tracks nfoWorks research, analysis, specification, and implementation of tools for document interoperability. There is commentary on related activities that address conformance, interoperability, and harmonization of document formats.
The nfoCentrale Blog Conclave
nfoCentrale Associated Sites
Technorati Tags: ODF-OOXML Harmonization, OpenDocument Format, interoperability, conformance, testing, validation, verification, open standards
It is sponsored by a neutral (ODF-supporting) organization. It is attended by major implementers of ODF-supporting products, including IBM, Microsoft, and Sun Microsystems.
In short, all of the right people are in the same room, some for the first time, and I am so envious that I am not among them. There should be a great deal of creative tension.
I will be watching for materials and progress reports. There is already Doug Mahugh’s useful pre-event post on how Microsoft tested the ODF implementation in Office 2007 SP2 to ensure that it only produced standard-conforming documents and failed in ways that did not introduce security exploits against the Office System or documents of its users.
I have been meaning to post more about my involvement with ODF and how it is fueled by my interest in the harmonious level at which we can start and expand interoperability based around standard, open formats for office-productivity applications. I will do that separately. For now, I just want to register my excitement for the positive stage that participation at this meeting represents.
[Update 2009-06-16-18:56Z There are little odds and ends available from the ODF Plugfest so far, and I will compile some links here for safe-keeping. I am sure there will be additional blog posts and reports by more attendees after they have had some time for reflection]
[Update 2009-06-17-17:11Z with a few more straggling in]
[Update 2009-06-18-17:51Z as other posts show up]
[Update 2009-06-23-14:55Z with some stragglers]
[Update 2009-06-24-18:55Z and one more interesting appraisal]
[Update 2009-06-27-21:40Z and the hits keep on coming …]
[Update 2009-07-01-15:25Z wrapping up, with anything more on plugfests in future posts]
Here are some apple-orange notions that have come to my attention in an oddly-convergent way.
New OASIS Technical Committee IPR Mode
OASIS has just announced the pending addition of a 4th IPR Mode to the set that technical committees can use as the way intellectual property (mainly essential claims of patents) will be made available to adopters of a TC-produced specification:
The ODF TC operates under the RF on Limited Terms Mode, the most-generous mode available until now. As stated under the OASIS IPR Policy, a TC may not change its IPR Mode without closing and submitting a new charter. I don’t expect such a shut-down and restart to happen, especially before ODF 1.2 becomes a ratified OASIS Standard.
Many will welcome this new mode. I know that my willingness to participate in OASIS Technical Committee activities increases exponentially as we move down the list. The RF on Limited Terms and the new Non-Assertion modes are the only ones that I have no hesitation about.
The Non-Assertion Mode is comparable to everyone obligated by the IPR mode having automatically made an equivalent of the Microsoft Open-Specification Promise with regard to the specifications produced by the TC during their participation.
Of course contributors, participants, and anyone else can provide non-assertion covenants with regard to any specification, as Sun Microsystems did for ODF in September, 2005.
Implementation License Models and Interoperability
The licenses under OASIS IPR modes apply to implementations of the applicable specifications, such as ODF.
I have recently been dealing with provisions of the ODF specification that do not seem to be understandable on their own, not even by consulting referenced source materials. In that case, there is no way to ensure interoperability without consulting an implementation or two. In complex cases (such as figuring out how to decrypt an ODF document that is encrypted using the approach sketched in the ODF specification), it is actually necessary to inspect code to determine what the missing but essential details might be. (It would be better to find implementation descriptions that explain how the specification is being satisfied, but too often the code is the only reliable implementation description.)
When the code is available in an open-source implementation, it may be possible to reverse-engineer an implementation-independent interoperable interpretation. That is what I would look for, assuming that I could master such code well enough to resolve questions the specification leaves open.
Consulting code works for detective work around clarification and hole-filling of the specification. If I want to make an implementation based on that interpretation, I must be especially careful about the license on that code. For example, LGPL and GPL code and other reciprocal-license open-source software is not useful to me in producing software under a license that I prefer (Open BSD, Apache, etc.). I am cautious about digging around in voluminous code anyhow, but I am particularly wary about risking that I might copy GPL code.
In this case, I am reluctant to rely too strongly on an abstracted interpretation unless the specification itself is updated and issued with an interpretation I can then safely rely on.
In effect, specifications that are sufficient for implementation-independent achievement of interoperability, along with royalty-free licenses or covenants, provide the ultimate clean-room support for achievement of unencumbered independent implementations.
That’s what I’m after.
Technorati Tags: open government, open government data, open principles, open formats, open documents, open data
It strikes me how much simpler and well-framed this discussion is, contrasted with the over-stated manifesto for document freedom.
Somehow, when it is about simply-described affirmative principles, it becomes simpler to grasp and to imagine the possibilities and opportunities that are afforded. Here are the key qualities around public government data public made open:
with reviewable compliance.
There is more to be found on the wiki, and anyone can register and add their questions and perspective to the fleshing-out of these notions.
One can splice open documents, especially the public’s documents, into this structure as well. This puts important context around the technological issues involved in having documents in formats that everyone can use and that are freely implementable in computer software.
This has me think of a few other qualities that might matter in both domains, especially around durability/permanence.
You might have some thoughts about this too. Visit the Open Government Working Group page for more.
created 2008-08-13-18:06 -0700 (pdt)