nfoWorks: Pursuing Harmony

I can't stand some things about the sidebar, and I must fix them now (template versions 0.04-0.05):

• The differences in font colors and weights between headings on the sidebar and the main body are repulsive.  The body heading colors work fine. [0.04 partway there]
    
• There is no list of recent posts (and how did I miss that?).  I am cribbing that from Orcmid's Lair.  [0.04 addition; 0.05 some appearance improvement]
    
• I may as well grab a list of related blogs while I am doing that. [0.04 addition; 0.05 some appearance improvement]
    
• I need to set the sequence on the model I am accustomed to as well:
  • Description, to be simpler, maybe smaller type
  • Atom feed indicator and symbol [0.04 addition]
  • Associated Blogs list [0.04 addition]
  • Blogger badge [0.04 move]
  • Search badge
  • Replacement of profile with smaller picture, blogs that link here, view my profile and technorati badge
  • ClustrMap [0.04 addition]
  • Recent Items [0.04 addition]
  • Archive [0.04 change - still need to fix fonts and appearance]
       
• I am self-hosting this blog, so the internationalization of static headings is irrelevant and I can simplify styles further [0.04 start]

I need to be careful and not attempt too much of this all at once.   This is going to be one of those pages that I will probably update as I make progress.

Update 2008-08-20T23:54Z: A set of provisional changes are made with template version 0.04 with the idea of tweaking further after seeing the template at work.

Update 2008-08-21T01:07Z: The biggest change is to get rid of link underlining and use bold-face as well as an improved link color.  This and some minor layout adjustments are accomplished with template version 0.05.  I am going to let those sit there for a while until I see how to make the layout more pleasant still.

Update 2008-08-21T01:14Z: The changes work better if I save the new template to Blogger after previewing it.

Labels: blogging, construction, nfoWorks

One problem for harmonization of document-format implementations in the case of ODF and OOXML is the degree to which those specifications may provide inadequate specification of how documents are to be presented in order for implementations to be adequately interoperable.  This situation arises between implementations of the same format as well as between different document formats.

Along with establishing clarity on how much agreement in presentation is required, there is the small matter of being able to somehow confirm that an application achieves whatever that level of conformance and interoperability is.

As I suggested in "Interoperable ODF: Finding Ground Truth," there are many difficulties to be conquered in advancing from the current state of affairs to where there is reliable determination that implementations are substitutable in a particular interoperability setting. 

We don't have good ways to even talk about the multiple, interlocking problems that lurk beneath the simple desire to have interchange of documents in standard formats "just work."

It would be helpful, for starters, to at least have a way to describe what a particular document-processing system does in rendering documents that it accepts.  A checklist on the handling of particular features of an electronic document is also useful in determining conformance and interoperability guidance and, perhaps, eventual mechanical verification criteria.

The XML Daily Newslink for 2008-08-18 reports on a contribution that may be useful in this regard, the "First Edition of ISO/IEC 24754: Minimum Requirements for Specifying Document Rendering Systems."  From the scope:

"This International Standard provides an abstract list of the features that a document rendering system may have, thus providing a frame of reference, against which the user and implementor can compare the  features of a document rendering system. However, this International Standard does not direct how each document rendering system should behave.

"This International Standard provides the minimum requirements to specify the features that a document rendering system which transforms formatting objects to rendering output. It may be used as a frame of reference, against which the user, implementer, or software agent may compare the features of a document rendering system.  According to these requirements, the user may express what he or she expects of a document rendering system, the implementer may describe the functionality and capability of the document rendering system that he or she implements, and the software agent may negotiate a minimum set of functionality and capability that are shared across different document rendering system implementations."

The Final Committee Draft (omitting the example in the informative appendix) is available as a 7-page, 74 kB PDF file. 

Beside the announcement, here's what attracted my attention:

• The list of features is abstract.  The descriptions of how individual feature are handled would normally be in prose, with possible reference to standards applicable to the feature (e.g., font substitution).
    
• The document assumes an abstract processing model related to that for SGML and XML.  The presumption is that rendering is specified separately from logical document format and content.  It can, of course, be adapted to the rendering provisions of processors for electronic office documents even though rendering conditions are embedded in the specification for the document format and its elements.  So it is definitely minimal and something to start from.
    
• This work was initiated in 2005.  The Final Committee Draft download file is dated 2007-10-29; its electronic document was last edited on 2007-01-23.  The standard, ISO/IEC 24754:2008 was published on 2008-08-15.  It costs 96 CHF (about $100 US) and is not (yet?) on the list of publicly-available (i.e., free) standards, last updated on 2008-08-08.

Labels: conformance, document rendering, interoperability, nfoWorks

Jesper Lund Stocholm has found his files from the Microsoft Document Interoperability Initiative ODF Workshop.  His post, "DII ODF Workshop - the good stuff", shares the nitty-gritty on-the-ground experience of transferring ODF documents from OpenOffice.org to Microsoft's pre-beta Office 2007 SP2 implementation and back again.  There's a download of eleven test files, each in two forms, along with PDFs of how they render.  There's an OpenOffice.org version of each document.  Then there's the Microsoft Office 2007 SP2 pre-beta ODF saving of the same document.  This is enough to discern how the the two applications handle application-specific features from other applications and express application-specific features of their own.

There are some great lessons becoming available with regard to interoperable use of document formats.  Here's what I see in terms of the Microsoft Office and OpenOffice.org implementations of ODF:

• Being standard is not the same as being interoperable. 
  Lund Stocholm points out, "The result of the validation is that all files generated by Microsoft Office 2007 SP2 are valid ODF 1.1-files."  The validation is essentially syntactical and that is not going to deal with all of the tolerated implementation variability, semantic bugs, and need for out-of-band agreements where the specification is (purposely and perhaps valuably) left wishy-washy.
     
• There's a tremendous amount of binary information packaged in OO.o 2.4 and Office 2007 ODF document implementations.
  This information is carried in outside-of-ODF namespaces and MIME types for which there is no mutual agreement.  This can be reconciled among the different implementations, and we might expect more harmony before Office 2007 SP2 ships, assuming there are no intellectual-property difficulties not covered by existing non-assertion covenants.  This is a tricky area with socio-political and competition-law ramifications (illustrated by how no one seems to be bothered by the amount of binary material used in OO.o's implementation of ODF).
    
• ODF-specification versioning is going to bother us for years, if not forever.
  Version churn is going to be a serious problem until those able to insist on demonstrable interoperability among applications compel some rational process for dealing with specification and implementation incompatibilities and defects,  The stakes are now raised for achieving useful up- and down-level accommodation of specification and (deviating but widespread) implementation versions.  Although I can see no way the ODF spreadsheet-formula problem could have been avoided, in particular, we must face two painful situations:
  • XML namespaces for ODF are not dealt with as contracted interfaces with explicit discrimination of additions and changes between versions of the specifications.
  • Requiring private agreement on spreadsheet formulas through at least ODF 1.1 is going to force dealing with at least three versions in the future, something like
    - a Microsoft Excel formula namespace (better: an ECMA-376 or IS 29500 one),
      xmlns:msoxl="http://schemas.microsoft.com/office/excel/formula"
    - an OpenOffice.org formula namespace,
      xmlns:oooc="http://openoffice.org/2004/calc"
    - the default ODF OpenFormula namespace when finally introduced into ODF
    - versions of the above with their individual defects and incompatible implementations
      
• It's the application [stupid?]
  People don't deal with formats and the nuances of format versions, allowed options, and private agreements.  People deal with software and the quality (and fidelity) of the electronic document that the software provides.  Expecting individual users to be self-consciously attentive to limitations on conformance and interoperability is even more hopeless than demanding meticulous adherence to security policies and practices in ordinary office work.  What people do want is for their interoperability case (however articulated) to just work.  In reality, even "Save as ..." is asking too much.
  • The first part of this lesson is going to involve recognition of the degree to which end-users are going to address interoperability by choosing specific software and believing interoperability is achieved, the ever-popular solution.
  • The second part of this lesson is recognition of the distance between the current state and one with broader interoperability and confident substitution of alternative software choices.  The differences among major ODF implementations will reveal how easy it is to lose interoperability while conforming to the current specifications.
  • Ultimately, we may have to accept that we are unwilling to pay the price for significant interoperability assurance except under extraordinary circumstances.  The "cost of interoperability" debate is ahead of us.

I don't foresee the Harmony Principles alleviating this situation in any way.  At best, I expect it to help us appreciate the cost of interoperability and its improvement over time.

Labels: interoperability, ODF, versioning

After having the template tweaks to look at, I am making some more, leading to version 0.03:

• First, I make an unrelated addition to the RSS feeds, following the advice of Amit Agarwal.  This is meant to deal with situations where the feed is mechanically republished by another site, preserving the origination of the feed item regardless.
  Each feed item will now have this footer:
  <hr /><a href="http://nfoWorks.org/diary/" target="_top" rel="nofollow"> nfoWorks: Pursuing Harmony</a>
    
• The entire sidebar is right-justified for more-consistent appearance.
    
• The title of the blog is centered.  Eventually, there will be a logo in the upper-left corner and some links in the upper right.

I've started capturing pages that illustrate the state of the blog at each template revision.  These will be carried under the Blog Operations materials for reference. 

Although I intentionally refrain from republishing the whole site, older archive and post pages will be regenerated from time to time.  Page regeneration, always using the then-latest template, is usually because comments have been posted and sometimes because I provide additional information in an older post (such as links to related recent material).

Labels: blogging, construction, nfoWorks