Blunder Dome Sighting  

Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.

Click for Blog Feed
Blog Feed

Recent Items
DMware: Office System Developer Conference 2008
Cybersmith: 10 Golden Rules for Mastery
Toolcraft: Making Discs from CD/DVD Image Download...
VC++ Novice: Obtaining VC++ 2005 Express Edition
VC++ Novice: Visual Studio 2008 Express Edition Ar...
CP4E: Novice Computer Programming and the OLPC XO
DMware: How About That ODMA64?
VC++ Novice: "Runtime Error!"
Cybersmith: APLN Seattle Meeting with Jim Benson
NWCPP: Herb Sutter - Things Your Programming Langu...

This page is powered by Blogger. Isn't yours?

Locations of visitors to this site
visits to Orcmid's Lair pages

The nfoCentrale Blog Conclave
Millennia Antica: The Kiln Sitter's Diary
nfoWorks: Pursuing Harmony
Numbering Peano
Orcmid's Lair
Orcmid's Live Hideout
Prof. von Clueless in the Blunder Dome
Spanner Wingnut's Muddleware Lab (experimental)

nfoCentrale Associated Sites
DMA: The Document Management Alliance
DMware: Document Management Interoperability Exchange
Millennia Antica Pottery
The Miser Project
nfoCentrale: the Anchor Site
nfoWare: Information Processing Technology
nfoWorks: Tools for Document Interoperability
NuovoDoc: Design for Document System Interoperability
ODMA Interoperability Exchange
Orcmid's Lair
TROST: Open-System Trustworthiness



ODF-OOXML: nfoWorks for Harmony?

see also:

1. In Search of Harmony

I want an office productivity suite that supports open-standard document formats exclusively.  And for any class of document (let's say word-processing, spreadsheet, and presentation to be specific), it only supports open-standard formats in that class in accordance with what I am calling the Harmony Principles:

  • Standards Compliant: All of the open-standard formats in a class are supported without prejudice: accept documents in the supplied format.  Produce documents in the same or different standard format as circumstances require.  If a particular community agrees to use a particular format, accept and return that format.  If a particular format is required for archiving, preservation, or submission to some authority, submit that format.
  • Always Harmonious: No features of a standard format are supported that are not perfectly and recognizably represented in all of the formats of the class: Everything created in one standard format is accurately expressible in any other.  Unsupported features encountered in input documents are suppressed in a graceful way; an understandable account is provided.
  • Specifically Interoperable: Because standards evolve and so do individual format-supporting software implementations, programs and their users can establish profiles that limit the harmonious features relied on in particular documents.  Harmony-supporting computer programs will conform their available features to the requirements of such profiles.

Given portable, open-source reference implementations of the essentials, there is opportunity for development of a Harmony for Windows, Harmony for the Mac, Harmony for Linux, Harmony for Google, Harmony for whatever.  Other products and implementations of the formats that deliver non-harmonious features could provide optional election of Harmony Principles, particularly whenever an interoperability profile is encountered. 

A Harmony suite could easily live alongside configurations of people's favorite broader-function office suite, just like Microsoft Works and similar mini-suites can be found by default on many computers that have additional productivity software.  Whether the components could be operated usefully together is an opportunity for innovation beyond the basic parameters of the Harmony Principles.

2. You Have Questions?  I Have Questions!

  • Q: Won't the interoperability intersection be so small that no one would limit themselves to it?
    A: Perhaps.  I have no idea.  Let's find out.
  • Q: Won't the performance of Harmony be worse than the optimization that is possible by dealing well with a single open-standard document format?
    A: In principle, probably.  In practice I expect a Harmony reference implementation to be noticeably less capable.  Optimization comes after figuring out how to do it at all and takes a substantial investment that only serious competitors might undertake.
  • Q: How Is "accurately expressible" determined?
    A: I don't know.  I'm thinking one measure would be achievement of the same presentation in some neutral medium, say some canonical PDF rendition that it is easy to compare against.  Another is roundtrip fidelity between different formats and back, in terms of what people see and what they can manipulate.  These strike me as variants on acceptance tests that are already needed for demonstrating conformance to a single open-standard format.  It will take experimentation to find adequate measures.
  • Q: You seem to put a lot of stock in profiles for constraining dependence on features.  Is this just more standards work?
    A: I don't know.  I don't think any of the current open-standard formats provide for constraint on the document architecture for some externally-defined, utilitarian purpose.  I don't think there is enough understanding about how this can be expressed across different (or the same) formats to consider whether there should be any standard for it.  Let's find out how to do it at all first.
  • Q: What makes you think that major office-productivity software producers would support the Harmony Principles?
    A: I have no idea.  I think it depends on first determining what is feasible under easy conditions, then see what is valuable to users of major more-complex and more-sophisticated software products.
  • Q: Is there anything you're sure of concerning the practical achievability of Harmony?
    A: I'm sure I don't know.  Oh, yes, and I am sure that it is bigger and more difficult than I can get my head around, especially operating alone in my private echo chamber.

3. Well Then, Let's Start Getting Started Shall We?

Something I am more confident of as a starting point is a suite of exploratory tools and exercises that I call nfoWorks.    That development can proceed along the following lines:

  • Deliver Concrete Artifacts.  Don't produce anything without working software and repeatable demonstrations and tests.  Do this early and often, no matter how crude. 
  • Operate Entirely in Public.  Use SourceForge, Wikis, etc.  Provide open-source software.
  • Start Very, Very Small.  Find the minimal cases that work for demonstrating and exercising open-standard document formats and isolating the interoperability intersections.  Build out incrementally and iteratively.  Always have something that works.
  • Make Tools and Instruments.  Build filters and conformance tests as a way to accept the proper formats, verify outputs, and check inter-translation of identified harmonious features.
  • Develop Measurable Harmony Principles.  Learn by doing and identify what it is that must be preserved across implementations/formats and how to tell that it is.
  • Devise Portable Approaches.  Don't get stuck on a single platform.  Design in portability for broad reuse.
  • GUI Applications and User Experience Come Last, if Ever.  So we are not talking about something, at this point, where end-user operability dominates.  Really.  We need to understand this problem at the nuts-and-bolts format-manipulation level.  After there is a clear path, step up to the very real difficulties of fitting into the ways that people actually operate without getting in their way [2].

4. Hmm, Now What?

I think I need to get my arms around the "start very, very small part" without losing site of the overall objective.  That may take some relaxed "get ready to get started" work. 

I probably don't need to know anything about changes to DIS 29500 (OOXML) as the result of the up-coming Ballot Resolution Meeting, but I think I will use that time and some of the aftermath to start providing details that are more substantial than this high-level thinking-it-over: Something others can get there teeth into.  This is not the kind of open-source project I can even think of doing single-handedly, so I need to think about how others can be engaged too.

What do you think?

I've been mulling over some sort of ODF-OOXML common document-processing approach for some time.  I'm using my preparation for ODC2008 attendance as a stimulant to putting something on the table. 

[1] Dennis E. Hamilton: Why Not .rtfx?  Professor von Clueless in the Blunder Dome (web log), 2007-03-26.
This came out of my tracking of the Massachusetts Information Technology Division list of qualified document formats under versions of their Enterprise Technical Reference Model.  I have more to say about opportunities to use Open Packaging Conventions as a powerful carrier for interchange of document-based artifacts.  This kind of project can also spin off as early application of nfoWorks fixtures, or vice versa.
[2] Dennis E. Hamilton: OOXML-ODF: The Harmonization Hope ChestOrcmid's Lair (web log), 2008-02-06 (2008-02-07 updates).
My ponderings over this post also improved my thinking about nfoWorks (including choice of name).   

[update 2008-02-08T11:02 -0800: I cleaned up some of the narrative and put the needed "?" in the title.  None of the tweaking is dramatic, but expresses my intention more carefully, I hope.]

Construction Structure (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 10-04-30 22:33 $
$$Revision: 21 $