nfoWorks: Pursuing Harmony

Republishing before Silence

2010-05-01T01:21:00.001-07:00

The nfoCentrale blogs, including Pursuing Harmony, were published through Blogger via FTP transfer to my web sites. That service is ending.

Then there will be silence as Blogger is unhooked, although the pages will remain.

No new posts or comments will work until I updated the web site to use its own blog engine. Once that migration is completed, posting will resume here, with details about what to know about the transition and any breakage that remains to be repaired.

Meanwhile, if you are curious to watch how this works out, check on Spanner Wingnut’s Muddleware Lab. It may be in various stages of disrepair, but that blog will come under new custodianship first.

The Real Challenge of Achieving and Sustaining Interoperability

2010-04-15T20:47:00.001-07:00

I recently encountered a new blog by Moritz Berger of Microsoft. Moritz’s first two posts reveal the ~~among~~ amount of goo and disruption there is beneath the surface of any attempt to collaborate when using standard office-productivity formats among different desktop software products.

I take Moritz’s posts as anecdotal demonstrations of the challenges that we face in attempting interchange and collaboration on documents using different products that claim support of the same standard. What we expect to be matter-of-fact and effortless is simply not so. The thornier problems of converting among formats place easy-going collaboration even farther out of reach.

In that spirit, I recommend Moritz’s latest offering: How To Enhance (Or Destroy) Collaboration.

I am not advocating abandonment of open standards development. But it is easy to see how there is a natural tendency for communities of adopters to settle on specific products that they all agree to use in order to avoid pitfalls and surprises beyond their control.

If the promise of product substitution and effective multi-platform support is to be made real, we have to become much better at knowing what it means when a product supports a format, how that support changes with new releases, and how this all sorts out when we throw different product implementations into the mix. We also need some way of actually knowing and safeguarding against use of product functionalities for which interoperability with other productions/versions is at best haphazard when not simply hopeless.

It looks like an uphill struggle. We must do better.

Let’s Try This for a While

2010-04-15T19:47:00.001-07:00

Here is my effort to find a smoother appearance for this blog.

After practicing with this for a while and making any further adjustments, I will republish the entire blog in this format for consistency and to have the Creative Commons notice appear on all pages of the blog.

[update 2010-04-16T04:00Z: I should point out that previous posts that discuss the format of the blog are in reference to a format that no longer exists on the main page and new posts. While there remain some color-scheme issues with the updates just completed, that’s nothing like the earlier problems. I will republish the entire blog once there is calm. That will make earlier posts about the blog format even more peculiar. I’m looking into ways to deal with that.]

Hooptedoodle: Blog Aversion and Standards Ignorance

2010-01-25T19:55:00.001-08:00

Technorati Tags: CSS Styles, web development, HTML, blog accessibility, Blogger

This is a maintenance post. I am twiddling with the template for this blog to see if I can like the result enough to start writing some pent up posts that I have been holding back.

The holding back is, apart from my usual procrastination, because I don’t like the design of this blog page. I just don’t like it.

[Update 2010-02-03T00:44Z It seems that Blogger is solving this problem for me. My love-hate relationship with Google Blogger is going to end with my long-overdue disintermediation from Blogger and graduation to self-publishing as well as the current self-hosting on my own domains and hosting-service arrangements.]

The New Is the Enemy of the What Already Works?

When I started the blog, I decided to use one of the newer ready-made Blogger templates that is all CSS’s and prettified and presumably standards-compliant in some elevated way. My original blog and its kin have templates from back in the day when HTML tables ruled. I understand those templates pretty well. For this blog, I thought I’d modern up.

As I grew to despise the new layout, I turned to my usual solution: hand tweaking the template, something that can be done by code-and-fix clueless manipulation of the template:

I keep a copy of the progressive changes to the original Blogger-furnished template under source control and I can always revert to an earlier version if I mess up really badly. There’s even a backup on the site, though it usually lags behind what I have locally and what Blogger is using at the moment.
Blogger allows preview of a new template without changing the still-in-effect template.

Both of these arrangements allow me to muck about without too much risk of completely cratering the blog.

So far, so good, right?

Maybe not.

At Sea In More “Standard” Than I Need

I haven’t figured out how to tweak the CSS and get the result I want. And I don’t know when modifications I make might will derail the bits and pieces that Blogger automatically inserts into these pages, following the guidance of specially-coded division classes and magical HTML elements with names like <$BlogDateHeaderDate$>.

I also don’t have the experience to discern whether the original CSS is very good and what the mound of CSS declarations in the <head> element of every page are required for. I would like to discard everything not actually being used and then simplify what is left. I’m not sure how to do that safely. And I don’t want to make a career out of CSS-crafting, either. I just want my blog pages to work.

So there is the wonderful preferred “standard” for correctness in web-page operation. But I can’t decode it enough to make my simple page layout work.

Not Backsliding Just Yet

If all else fails, I will bring over one of my old templates and turn it into one from this blog, rather than attempt to achieve my goal by hacking and hewing on the current CSS-purified design.

Unfortunately, that makes things work with, shudder, the dreaded and feared <table> elements.

I’m not ready to do that, because one difference in the current format is that it appears to be mobile-ready. Now, I don’t care all that much whether you can read this post on your telephone. Still, why lose it if I’ve got it.

A greater concern is the still missing support for accessibility. While someone may claim that giving up tables for CSS is good for accessibility, it doesn’t actually do anything for accessibility of this site.

I will keep mucking about and we will see where things end up. It is not promising. I’m not likely to dig out the CSS1/2 specifications to see how this all really works. If a little trial-and-error doesn’t cut it, I’ll just struggle along anyhow.

The Old Dog’s Old Trick

I didn’t mind learning HTML. I didn’t mind learning enough of HTML 4.01 transitional to get along. Why am I avoiding the latest and greatest or even the recent and still breathing approaches?

I think the difference is that there is no novelty any longer, after acquiring what I needed that was good enough at the time. What’s next is simply different, but for what I do not noticeably better or interesting. The old dog doesn’t want the new shiny thing because the old shiny thing was working just fine. It’s not a new trick, it’s a different trick, and novel only for those whom it their first trick.

And I haven’t given up just yet. Not in a rush about it either.

Meanwhile, this is a test post to exercise the blog template de jur.

ODF Implementation-Support Toolkits and Libraries

2009-12-05T11:26:00.001-08:00

Technorati Tags: open source, open formats, interoperability, open development, OpenDocument Format, ODF-OOXML Harmonization, ODF

I have no appraisal of the relative maturity and quality of the various toolkits that are emerging on the ODF scene (and likewise with regard to OOXML). However, it is important to have a cataloging of what there is. This is a random start. I will add to this post and build an nfoWorks catalog page later:

lpOD: languages & platforms OpenDocument Project (also Français).
Definition of a Free Software API implementing the ISO/IEC 26300 standard.
Development, for higher level use cases, in Python, Perl and Ruby languages.
of a top-down oriented API. Licensing is under Free Software Foundation (FSF) versions.
- 2009-12-04: lpOD 0.8 release (via Rob Weir)

My interest

An important resource for ways to harmonize document formats involves attention to the libraries and models employed for constructing document-centric software and their applications. This applies for the development of testing and conformance tools as well as for implementation of format-supporting software products. Indeed, one might reasonably expect that such tools would be a companion demonstration of implementation-support quality.

In the interesting case of OpenDocument Format, the availability of open-source code bases for implementations is both a risk (in that deviations or omissions in support for the standards is are perpetuated through code mimicry) and an opportunity for faster tooling and testing. Of course, closed-source implementations (and related toolkits) have their own dangers in this regard, while denying public inspection of the code. I suspect that implementation notes are required in all cases to ensure understanding of intentions and interpretations as well as limitations and the different ways that discretionary matters are handled.

For ODF, the continuing work on toolkits and on independent open-source implementations is providing important diversity. This can inform the search for a harmonious profile and perhaps suggest adaptations that encourage harmonious implementations. Diversity across platforms and programming models may also help in the recognition and abstraction of essentials away from implementation incidentals. That can also be valuable in ensuring that harmonization is on essentials and not accidents of implementation.

I will be reviewing available toolkits, libraries, and APIs as I define my own around interface contracts for abstracted levels of document models and processing support. I expect some cross-fertilization while adhering to a model that is concentrated on harmony.

Adding Pursuing Harmony to Technorati

2009-09-08T16:01:00.001-07:00

vfa6zt4r3h

Just a little housekeeping. This is a little secret message between me and technorati.

Technorati Tags: techorati, Pursuing Harmony, orcmid, blogging

Office Shots for Confirmed ODF Interchange Fidelity

2009-06-19T10:58:00.001-07:00

Technorati Tags: Officeshots.org, ODF, interoperability, document interchange, document fidelity, confirmable experience

The new Officeshots.org service received a fair amount of attention at the recent ODF Interoperability Plugfest. Taking a page from the “test your site with all browsers” tools that are available, Office Shots will take an uploaded ODF document and show how it renders in different ODF-supporting products. To deal with the problem of confirming appearance of the document back to the submitter, the rendering by each application is captured in PDF.

This is a fledgling service, currently in limited beta. It is sponsored by the same Dutch organizations that sponsored the ODF Plugfest.

The power of the service is its user-relevant confirmation of the fidelity with which a document of interest is rendered by different ODF-supporting software/platform combinations. It is an easy way for evaluators to verify whether their important documents are rendered successfully in interchange among ODF products. It also allows the subjective determination of success to be left in the hands of the users who know what qualifies as acceptable fidelity in each particular case.

One of the most-difficult situations in interchange of documents is when the receiver is seeing something materially different than what the sender (1) had in mind and (2) expects has been communicated. For the parties to communicate about a suspected difficulty, they need to use a “channel” that differs from the one that has apparently failed. Screen shots serve that purpose. PDF is also valuable in the case where a PDF can be extracted that accurately-enough reflects what is intended and/or what is being seen.

Office Shots provide a way to proactively check, either because a problem is suspected with a local rendition or to ensure that a document and the choice of implementation-supported features is treated consistently by a variety of other implementations/platforms.

One can imagine that, over time, we could see Office Shots support links for troubleshooting specific discrepancies, finding practices for avoiding many of them, and easy reporting of problems to development teams.

Office Shots promises to provide a terrific reality-based approach to confirming the interoperability of ODF implementations as far as presentation fidelity is concerned. This is also a first-line check on confirming difficulties with round-trip inter-product fidelity preservation. (Of course, if the goal is solely presentation fidelity, PDF and other final-form formats may be preferable, especially when long-term preservation is also a consideration.)

I look forward to the impetus that Office Shots will provide to user recognition of practical ODF interoperability considerations. I also think it will provide important stimulus and confirmation for developers who want to improve the interoperable use of their ODF-supporting software.

Beside the Officeshots.org site, there are other discussions of the project and its potential:

Glyn Moody: ODF and the Art of Interoperability. Open Enterprise (blog), ComputerworldUK, 2009-06-19.
Sander Marechal: Easily testing ODF compatibility (odp, pdf). Presentation to the ODF Plugfest, 2009-06-15. [In this case, the PDF renders more poorly than the ODP on my computer. I assume the problem is in the production of the PDF via the ODP implementation, yet another Officeshots interoperability case.]
Sander Marechal: Officeshots.org. Product submission, OpenDocumentXML.org, 2009-02-06.

ODF Interoperability at The Hague

2009-06-15T12:12:00.001-07:00

Technorati Tags: ODF-OOXML Harmonization, OpenDocument Format, interoperability, conformance, testing, validation, verification, open standards

There’s a great event at The Hague these two days: June 15-16, 2009. It’s all about OpenDocument Format (ODF) and interoperability.

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]

ODF Plugfest Workshop Site
ODF Plugtest Wiki
Twitter: #odfplugfest hash-tag
Day I Schedule and Program
2009-06-15-12:01Z Doug Mahugh, “Live Action Photo”
2009-06-15-13:25Z Doug Mahugh, “Free-Form Discussion”
2009-06-15-15:54Z Doug Mahugh, “Soothing Twang”
Day II Schedule and Program (with links to presentations)
2009-06-16-08:30Z Fabrice Mous Slides on Slideshare
Favorite note (via Floschie [during Rob Weir’s presentation?]), “Other possible work: Standardize OpenFormula at OASIS before !ODF 1.2 to improve current situation”
2009-06-16-11:45Z Doug Mahugh, “Working through Interop Scenarios”
2009-06-16-12:45Z Doug Mahugh, “Reporting Live”
2009-06-16-13:14Z Florian Schießl, Floschi’s Blog: “ODF plugfest version 1.0 released”
2009-06-16-13:19Z Twitter Interview with Microsoft’s Hans Bos (Dutch)
2009-06-16-14:57Z Doug Mahugh, “Panel Discussion”
Favorite quote (via Floschie), ‘Peter Amstein (Microsoft): "Should be possible to define [by users] minimum featuresets in documents for interoperability"’

[Update 2009-06-17-17:11Z with a few more straggling in]

2009-06-17-06:09Z Doug Mahugh, Office Interoperability blog: ODF Plugfest, The Hague
2009-06-16 Doug Mahugh Flickr Photostream from The Hague (browse left)

[Update 2009-06-18-17:51Z as other posts show up]

2009-06-17 ODF Alliance Press Release: New ODF Interoperability Initiative Launched At Dutch Government Workshop (PDF download) [via Fabrice via Wouter]
2009-06-18 NOiV Announcement: Improving Interoperability ODF in Office Applications (English; Dutch here) [via Fabrice]
2009-06-17 Fabrice Mous, blog: El Ombligo del Mundo (De Navel van de Wereld) (Dutch)

[Update 2009-06-23-14:55Z with some stragglers]

2009-06-19 Carol Geyer: ODF Plugfest at The Hague. (news item) OpenDocument.xml.org
2009-06-23 NL: Minister calls on software developers to fix ODF interoperability. (news item) OSOR.eu Open Source Observatory and Repository (via Alex Brown).
2009-06-23 Rob Weir: ODF TC timeline. (blog post) An Antic Disposition. A version of Rob’s presentation at the ODF Plugfest.
2009-06-23 Rob Weir - From ODF pre-1.2 to ODF 1.2 (video). (news item) Boycott Novell. I recommend this video for the brief timeline and standards lifecycle review that Rob talks through. I particularly recommend the last part on participation and all of the ways that interoperability can be developed and strengthened for ODF.

[Update 2009-06-24-18:55Z and one more interesting appraisal]

2009-06-23 Sven Langkamp: ODF Plugfest. (blog post) Sven’s Blog. Useful perspective regarding participation by KOffice, an independent implementation of the ODF specification.

[Update 2009-06-27-21:40Z and the hits keep on coming …]

2009-06-26 Rob Weir: ODF Plugfest. (blog post) An Antic Disposition. An essay on the origin and value of plugfests and a thesis on what interoperability is desired and what the prerequisites are. Bonus: A great image from the event.
2009-06-27 Roy Schestowitz: Lunch with Microsoft to Talk About ODF, Which it is Attacking. (blog post) Boycott Novell. For balance, an advocacy view based on always seeing what you are looking for and using repetition of your own claims as evidence. A reality-check calibration: Citation of this blog squib as the expression of a Free Software Foundation “position.”

[Update 2009-07-01-15:25Z wrapping up, with anything more on plugfests in future posts]

2009-07-01 Roberto Galoppini: An ODF Plugfest a Day Take the Doctor Away. (blog post) Commercial Open Source Software (via Rob Weir). Interesting use of tags. There are many useful links to other posts and articles on the Plugfest and related ODF and open-source topics.
2009-06-22 Roberto Galoppini: ODF Interoperability: Rough Consensus and Running Code (blog post). Commercial Open Source Software.
2009-06-19 Jos Poortvliet: KOffice Developers At The First ODF Plugfest. (article) KDE.news. More on KOffice team experience at the plugfest. (via Roberto Galoppini)
2009-06-12 Roman Korchagin: Aspose.Words participates in the ODF Plugfest Interoperability Workshop. (blog post) ASPOSE web site. (via Roberto Galoppini)

ODF and IPR/Licensing Concerns

2009-06-09T13:34:00.001-07:00

Technorati Tags: OASIS, OASIS ODF TC, intellectual property regime, IPR, open-source, GPL

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:

RAND Mode, requiring the essential IPR of participants and contributors to be licensable under Reasonable And Non-Discriminatory terms
RF on Rand Terms Mode, a Royalty-Free RAND mode that may have certain limitations
RF on Limited Terms Mode, where the limitations allowed to RF on Rand Terms are not allowed
Non-Assertion Mode, the new mode in which all contributors and participants make a non-assertion covenant with regard to the specifications that obligate them to do so

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.

Open Government Data: Simple Principles

2009-03-29T12:27:00.001-07:00

Technorati Tags: open government, open government data, open principles, open formats, open documents, open data

I finally noticed the Open Government Data Principles and associated Open Government Data site and Wiki (via Doc Searls).

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:

Complete
Primary
Timely
Accessible
Machine-processable
Non-discriminatory
Non-proprietary
License-free

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.

2009-03-25: Document Freedom Day

2009-03-25T17:55:00.001-07:00

Technorati Tags: document freedom, open formats

Yesterday, Ada Lovelace Day, I learned that today, March 25, is Document Freedom Day (via Louis Suarez-Potts).

Today’s celebration has the over-the-top theme: “global day for document liberation.” The thesis is that

“In a world where records are increasingly kept in electronic form, Open Standards are crucial for valuable information to outlive the application in which it was initially generated. The question of Document Freedom has severe repercussions for freedom of choice, competition, markets and the sovereignty of countries and their governments.”

…

“The Document Freedom Day (DFD) is a global day for Document Liberation with roughly 250 active teams worldwide. It is a day of grassroots effort around the world to promote and build awareness for the relevance of Free Document Formats in particular and Open Standards in general.”

A Little Less Manifesto Please

I fancy the simpler notion of promoting “document formats that can be used by everyone and safely implemented in free software.”

I must also caution that the existence of such a format does not assure that my computer-maintained documents will be able to survive intact beyond the availability of the specific software that I use to create and present them. There is no causality here, as much as we would like there to be. There is, on the face of it, a greater opportunity, but not necessarily one that I can exploit on my own.

Owning My Own Documents

Having said that, here’s what document freedom means to me:

There is a public format,
The format is safe to support in computer software without any limitation,
The stable preservation of the format and the consistent availability of freely-available supporting software are assured into the indefinite future.

That would satisfy me that I am truly the owner of my computer-supported documents.

It takes more to satisfy me that the choice of different platforms and products is a minor concern and there are reliable substitutes. That would require that the level of interoperable use among (versions of) document-processing products be so high that faithful interchange of our documents and even successful roundtrip collaboration in their development and refinement are assured.

Too Slippery the Slope

I think that is worth striving for. I don’t think we are close yet. I don’t think any of the sloganeering and posturing is doing anything to accomplish it. There are too many mixed agendas:

Ideological straight-jacketing: Confusing the means with the goal and demanding more of the means than the goal requires, even to a willingness to sacrifice the goal to the means
Magical thinking: Assuming that a given step is closing the approach toward the goal without any reality check or a way of measuring achievement of the goal and of mileposts along the road
Negativity: Opposing something rather than creating something, as if the elimination of the negative will assure the imagined positive

The Public’s Documents in Public Formats

There needs to be some serious reality-based assessment and measurability. That’s what it takes to be secure in the ownership of my documents. That’s what it will take to be sure that those documents that are the instruments of our civil society are indeed the public’s documents, using the public’s formats.

The lingering question, one to ask on next year’s Document Freedom Day, and then the year after that, and …, is who are the stakeholders and what action will they take to substitute reality for blind flag-following?

[update 2009-03-26T01:06Z: I should simply go to Rick Jelliffe’s blog before I open up my mouth about anything to do with open formats. If I could ever find the blankety-blank RSS feed I would be so much happier. Meanwhile, here are some relevant words on the status quo and the sow’s ear:

Rick Jelliffe: Does an ‘open format’ provide the benefits it is supposed to? 2009-03-22, um, the very topic we are speaking of
Rick Jelliffe: Another leap forward for openness? 2009-03-25, a bit of an insider cat fight surrounding the more acute question around who are the stakeholders for securing public ownership of the public’s documents. Is it really good for open formats that developers are the arbiters of what documents last? (I’m still reeling from “To me, the phrase ‘If it ain’t broke, don’t fix it’ is seriously anti-innovation and anti-intellectual.”)
Rick Jelliffe: Master Blaster. 2009-03-20, a compilation of Peter Sefton snippets on how dismal things are when the most successful interoperability is between Microsoft Office and OpenOffice.org using (wait for it) … Office binary formats for round-tripping. I am beginning to understand Rick’s HTML interoperability as the floor case for ODF Text and OOXML WordProcessing documents.
Rick Jelliffe: MODUS – Minimum Open Documents Using Standards. 2009-02-26, rather deeper than the other ones, out to identify a technical approach to assured interoperability/interchange in a practically-satisfying way. The part on Verifiability I must print out and put under my pillow every night.]

Retiring InfoNuovo.com

2008-12-31T08:51:00.000-08:00

Technorati Tags: infonuovo.com, InfoNuovo, ODMA, nfoCentrale.com

[cross-posted 2008-12-29T16:49Z from Orcmid’s Lair. Some of the oldest links that still use the infonuovo.com domain are related to ODMA. This post is here to catch those who might end up searching for previously-found ODMA material and wonder where it has gotten too and happen to have an interest in the integration of content-management as well as document interoperability.]

I am retiring the InfoNuovo.com domain after 10 years. The domain will be cast loose at the beginning of February, 2009. Those places where there are still references to infonuovo.com need to be updated:

infonuovo.com, my original “anchor site” for several topical web sites, is now replaced by nfoCentrale.com. From now on there is no reason to refer to either infoNuovo.com or nfoCentrale.com (or its partner, nfoCentrale.net). The topical web sites have their own domain names. Those domain names should be used in bookmarks everywhere.
infonuovo.com/odma will continue to be found at ODMA.info
infonuovo.com/dma will continue to be found at DMAtech.info
infonuovo.com/orcmid will continue to be found at orcmid.com
infonuovo.com/dmware will continue to be found at DMware.info

and so forth for any other infonuovo.com links that may be tucked-away somewhere.

If you have an infonuovo.com bookmark and you are not sure of its replacement, simply use it and notice the URL of the destination that appears in the address bar of your browser. That is the URL that should be bookmarked.

InfoNuovo.com was the first domain name that I ever rented. It was originally hosted on VServers and absorbed through acquisitions a couple of times. On March 22, 1999, I posted my first construction note on the use of InfoNuovo.com as an anchor site, a web site that houses other web sites as part of a single hosting. This was also the first step toward evolution of what I now call the construction structure of any nfoCentrale web site. InfoNuovo was the company name I had chosen for my independent consulting practice initiated on retirement from Xerox Corporation in December, 1998.

When I moved from Silicon Valley to the Seattle Area in August, 1999, I found that InfoNuovo was too easily confused with a name already registered in Washington State. The business became NuovoDoc, but I continued to hold the infonuovo.com domain name for the support of the subwebs housed there. I eventually moved most content to the new anchor, nfoCentrale.net, on Microsoft bCentral.

There was one problem. Although I could redirect unique domain names, such as ODMA.info, to the current anchor, the web pages still served up with the URLs of the actual location on the anchor site. I experimented with URL cloaking, but that created as many problems as it solved.

In October 2006, following the lead of Ed Bott, I switched to A2 Hosting as a way to reduce the hosting fees and also take advantage of the A2 shared hosting Apache-server provisions for addon domains. Addon domains serve up with URLs of their domain even though the domain is anchored on a single hosted site (in this case, nfoCentrale.com). I consolidated all nfoCentrale.net and infonuovo.com content on nfoCentrale.com. I also parked domains nfoCentrale.net and infonuovo.com where they are today, atop nfoCentrale.com. Now, however, accessing any of the individual subwebs triggers redirection to the appropriate addon-domain URL.

This took care of my wanting to have the subwebs always respond as the domains that I have as their addons. It also raised an unexpected problem around case-sensitivity of Apache filenames, a situation I am still digging my way out of. That shows how important having the addon-domain capability is to me. I’m not sure I’d have moved if I knew how difficult the case-sensitivity extrication would be though.

I know that there are still infonuovo.com URLs out there, even though the addon domains have been in place for over two years. In another month, those URLs will fail. I just don’t want to lease infonuovo.com any longer. I do feel a little sentimental about it. That’s not going to stop me.

ISO/IEC 29500:2008 OOXML Standard Available

2008-11-19T10:00:00.001-08:00

Technorati Tags: ISO/IEC IS 29500:2008, OOXML, IS 29500, ISO Standard

Thanks to the ever-vigilant Alex Brown (and his convenient proximity to European time zones), we now know that IS 29500:2008, the ISO/IEC Standard for Office Open XML File Formats (OOXML to its friends) is now available from ISO.

The 4-part standard and its “electronic inserts” are provided on a CD-ROM. The purchase price is 342 CHF (about $285 USD or 225.5 EUR). Not exactly a holiday stocking-stuffer, but there are other ways.

Rumor has it that ECMA will now issue IS 29500:2008 as a revision of ECMA-376, and that will be available for free download (and sometimes there is a CD-ROM compilation made available from ECMA and we could expect OOXML to be included).

Even better than waiting for ECMA, IS 29500 is now on the ITTF list of Publicly Available Standards. As of today, the individual parts and their electronic inserts are available for download. Scroll down to the end of the Publicly Available Standards list and you will find the 7 links to the parts and their inserts. After accepting the license agreement for your personal use of each download, the Zip files will be on their way to your computer:

IS 29500-1:2008 Fundamentals and Markup Language Reference
- c051463_ISOIEC 29500-1_2008(E).zip, 40,824kB PDF in 32,984kB Zip
- c051463_ISOIEC 29500-1_2008_Electronic_inserts.zip, folder of 5 Zip files in 14,478kB Zip
IS 29500-2:2008 Open Package Conventions
- c051459_ISOIEC 29500-2_2008(E).zip, 1,823kB PDF in 1,501kB Zip
- c051459_ISOIEC 29500-2_2008_Electronic_inserts.zip, folder of 2 Zip files in 6.69kB Zip
IS 29500-3:2008 Markup Compatibility and Extensibility
- c051461_ISOIEC 29500-3_2008(E).zip, 929kB PDF in 833kB Zip
IS 29500-4:1008 Transitional Migration Features
- c051462_ISOIEC 29500-4_2008(E).zip, 10,143kB PDF in 8,221kB Zip
- c051462_ISOIEC 29500-4_2008_Electronic_inserts.zip, folder of 2 Zip files in 290kB Zip

The Electronic inserts include schemas in both Relax-NG and XML Schema. The IS 29500-1 inserts also include drawing geometries, spreadsheet styles, and word-processing art borders. The schemas with IS 29500-1 are for strict OOXML. The transitional schemas are with IS 29500-4.

One advantage of having these downloads, today, is having desktop search for locating material in them. That, along with the Acrobat Search for individually-opened PDFs, makes it possible to rely on this material as off-line but on-board references.

Until I stumbled on Alex Brown’s tweet following a very satisfying OASIS ODF Interoperability and Conformance TC coordination call, I had not realized how much I have been suppressing myself in anticipation of the availability of IS 29500 in tangible, public form. It was a little bit like waiting for US Presidential Election results (which happened much more quickly, although the long run-up was certainly comparable).

I’m not sure why it was like that, since there is plenty of work to do with ODF as part of my attempt to apply the Harmony Principles. Yet the missing-in-action status of IS 29500 was some sort of cloud over my attention and enthusiasm. Now, instead, I am suddenly much farther behind in this work than I was just 12 hours ago, and that was behind enough. Stay tuned …

[update 2008-11-20: I forgot to set categories. Done now.]

Cover Pages: W3C Multimodal Architecture and Interfaces

2008-10-30T11:32:00.001-07:00

Technorati Tags: Cover Pages, W3C, multimodal architecture, MMI, multimodal interfaces, document behavior, document content, interoperability

[update 2008-11-06 I don’t know how I failed to see that the very first sentence didn’t carry the sense I intended for it.]

A current weakness in the open-document standards arena is the poorly-specified and tacit coupling of format provisions to behavior in various document processing contexts (creation, viewing, editing/manipulation, and various “final-form” renderings and, these days, interactive performance governed by the document, whether slide-show or something more elaborate).

We’ll get to that some day, and the ways that such aspects are layered into specifications and their allowance for application innovation and conformance novelty remain to be discovered.

This Cover Pages Daily Newslink item from 2008-10-21 leads to an account of the W3C Technical Report on Multimodal Architecture and Interfaces Fifth Working Draft.

I’m putting down an nfoWorks marker because of these intriguing passages in the Newslink:

“The main difference from the previous draft is the addition of the rules and guidelines which will allow modality experts to describe the features, capabilities and APIs for specific modality components in sufficient detail so that the components will be interoperable in implementations of the Multimodal Architecture. … The specification describes a loosely coupled architecture for multimodal user interfaces, which allows for co-resident and distributed implementations, and focuses on the role of markup and scripting, and the use of well defined interfaces between its constituents.”

I am hesitant about the following:

“This framework places very few restrictions on the individual components or on their interactions with each other, but instead focuses on providing a general means for allowing them to communicate with each other, plus basic infrastructure for application control and platform services … At runtime, the MMI architecture features loosely coupled software constituents that may be either co-resident on a device or distributed across a network. In keeping with the loosely-coupled nature of the architecture, the constituents do not share context and communicate only by exchanging events.”

There are some wise words about keeping straight the different design-time and run-time considerations.

I suspect that this is not going to bear directly on realization of the Harmony Principles, but it might provide useful conceptual underpinnings for an account of the behavioral aspects that are at least as important in document-mediated interoperability as the standard document format.

Content Assembly for nfoWorks?

2008-10-15T13:18:00.001-07:00

Technorati Tags: OASIS, CAM, document profiling, verification, testing, Content Assembly Mechanism

Also from the Cover Pages: XML Daily Newslink for 2008-10-14, there is word of jCAM, an open-source, Java-based CAM XML Processor and Template Editor. The SourceForge Project has the software; the web site has more information and tutorials.

The focus of the OASIS Content Assembly Mechanism (CAM) TC is on information management of XML documents used for business transactions. What attracts my attention is that

“The vision of the CAM work is for describing machine-processable information content flows into and out of XML structures … .”

Some of the lingo is opaque to me, but I do have interest in automated approaches that involve

integration with metadata semantics
registration of metadata vocabularies
documentation of information exchange formats
validation of transaction instances
runtime creation of valid transaction documents

I may have problems in the validation and filtering of documents and test suites that are not at the proper scale for CAM. I do think it is worth examining for ideas and applicable techniques. This is my placeholder reminder for that.

DITA for Technical Standards Publishing

2008-10-15T12:40:00.001-07:00

Technorati Tags: DITA, OASIS, technical standards, XML

From the Cover Pages: XML Daily Newslink for 2008-10-14, there is announcement that the OASIS Darwin Information Typing Architecture (DITA) Technical Committee has formed a new subcommittee. The DITA for Technical Standards Subcommittee has the ambitious purpose of furthering and promoting DITA use for the creation, maintenance, and support of technical standards specifications. The idea is to have a “common standard for the creation and publication of … technical standards specifications:”

“The first effort will be to assess and define common requirements for the maintenance and publication of technical standards. This will provide the common requirements for the specific capabilities that DITA should provide. Finally, the group will create necessary enhancements to DITA standards and deliverables, including the DITA Open Toolkit with a Toolkit for Technical Specifications.”

There is more in the announcement of subcommittee formation on the (semi-official?) DITA online community site. The official subcommittee operation is to be set up on the OASIS DITA TC page.

I’m not sure that this has any near-term benefit, but it does arouse my interest in another way. I am finding it very difficult to wrap my head around the current and in-progress OpenDocument Format (ODF) and Office Open XML (OOXML) specifications. I need some way to wrestle out my understanding in a way that allows me to surface a conceptualization of the functions of either in a way that their reconciliation at the Harmony Principles level can be grasped and described in some useful way.

DITA surfaces on my radar from time to time. It is something I think I should know more about. I don’t know how to apply it in the context of standard document formats, nor am I clear how it is applicable to the conceptualization and expression of document-format standards. It does strike me that some help is needed, based on my early efforts in the analysis of ODF specifications. (At this point, concept-mapping software might be even more useful, and I will look into that as well.)

It is time to dig deeper into DITA to see how it can support a harmonization effort with regard to office document formats and their harmonizable specification.

Simplifying Speech-Enabled Applications

2008-10-15T12:02:00.001-07:00

Technorati Tags: text-to-speech, W3C, Harmony Principles, interoperability, document rendering, document accessibility

Via the Cover Pages: XML Daily Newslink for 2008-10-14, I learn that the W3C has standards for speech-enabled/-enabling web applications. The addition announced today is the W3C Pronunciation Lexicon Specification (PLS) Standard. This is an accessibility as well as a convenience feature. PLS is intended to work with Text to Speech (TTS) and VoiceXML applications.

The PLS lexicon is an XML document and there is allowance for blended use with other namespaces. This suggests to me that there is prospective use in interchange of office-productivity documents for various purposes.

I don’t expect that this will fit into any foreseeable level of harmonized features. I am placing this marker because it may well feature in accessibility provisions at some point, even if accomplished via a public-profile agreement involving foreign elements.

The accessibility angle is an important one to keep an eye on for its interoperability, interchange, and preservation potential.

Document Interoperability: The Web Lesson

2008-09-07T16:21:00.001-07:00

Technorati Tags: interoperability, IE8, web site construction, web standards, compatibility, conformance, document preservation, document formats

"are there alternatives to google groups search for searching old USENET messages? because groups date fielded search is teh broken."

-- Richard Akerman on Twitter, 2008-08-31

Be prepared for a dramatic shift in the reality of web-site browsing and the honoring of web-page standards. The pending release of Microsoft Internet Explorer 8 is going to put the reality of web standards and their loose adherence in our faces. Although Internet Explorer is indicted as the archetypical contributor to disharmony on the web, Internet Explorer 8 is going to challenge all of us to deal with the reality of our mutual contribution to the current state of affairs.

Here is a lesson, probably many lessons, for document interoperability and the way that standards for document formats evolve and harmonize, or not, over time.

The Web as Clinical Science

The movement from loosely-standard pages and their browsing to strictly-standard pages and standards-mode browsing will illustrate every aspect of the same challenge for office-productivity documents and the office suites that process them.

Web pages are the experimental drosophilae of digital documents. All aspects of dynamic convergence on standards, themselves evolving, and the forces of divergence, are demonstrated clearly and rapidly. I expect it to take Internet generations for significant convergence, with no static level of standards adherence anywhere in sight. It took us almost 20 years to get to this point on the Web; I figure it will take at least five more to dig out of it far enough to claim that there is a standards-based web in existence and in practice. I'm optimistic, considering that HTML 5, the great stabilization, is not expected to achieve W3C Recommendation status until 2012.

No document-interoperability convergence effort is anywhere close to the promising situation of the web as Internet Explorer 8, HTML5 implementations, and other compatibility-savvy browsers roll out over the next several years. It is useful to use that situation to calibrate how convergence and interoperability could work for document interoperability. There are significant technical barriers. The non-technical barriers are the most daunting. That should be no surprise.

Versioning in Document Use

I've written on Orcmid's Lair about the IE 8.0 Disruption. This involves changes in Internet Explorer 8.0 by which web pages are rendered in standards-mode on the assumption that pages are conformant with applicable web standards. In the past, it was presumed that pages were loosely-standard and browsers, also loosely-standard, made a kind of best effort to present the page. The consequences have been explained marvelously in Joel Spolski's post on Martian Headsets.

We are similarly relying on document-format standards as a way to provide for many-to-many interchange and interoperability between different (implementations of versions of) document-format standards and different (implementations of versions of) processors of those digital documents. That means we have a version of the loosely-standard documents with loosely-standard processing problem. We can't be strictly standard because the standards can't (and definitely don't) have strict implementations at the moment; and there are many ways that specifications and implementations have been kept loose by design. Accompanying that looseness by design is the the simple fact of immaturity among the contending document-format standards for office applications, particularly as vehicles for interoperable applications.

For office-productivity documents as we know and love them, there are five, count 'em five "official standards."

The "Official" Public Standards of Office Documents

For Office Open XML Format (OOXML), there is the ECMA-376 specification of December 2006. There is also the ISO/IEC 29500:2008 Office Open XML File Formats standard once it is made available. IS 29500 will have some substantive differences from ECMA-376. We won't have a solid calibration of the differences until the IS 29500 specifications are available and subject to extensive review.

For the OpenDocument Format, there is the Open Document Format for Office Applications (OpenDocument) v1.0 OASIS Standard issued 1 May 2005. There is also the ISO/IEC 26300:2006 Open Document For Office Applications (OpenDocument) v1.0 standard (also on the publicly-available listing). IS 26300 is for the same format as the OASIS v1.0 standard, but it is on a completely-separate standards progression. Appendix E.3 accounts for the differences of IS 26300 from the text of the May 2005 OASIS Standard. The first page of the IS 26300:2006 document (page 5 of the PDF) identifies its source as Open Document Format for Office Applications (OpenDocument) v1.0 (Second Edition) Committee Specification 1, dated 19 July 2006, derived from document file OpenDocument-v1.0ed2-cs1.odt; this is not another OASIS Standard, however.

The second and latest OASIS Standard for ODF is Open Document Format for Office Applications (OpenDocument) v1.1 issued 2 February 2007. This document is derived from OpenDocument v1.0 (Second Edition) Committee Specification 1, the same specification that is the source of content for ISO/IEC 26300:2006. The changes made to arrive at ODF v1.1 from the v1.0 (Second Edition) committee specification are detailed in Appendix G.4. There are some mildly-breaking changes from ODF v1.0 to ODF v1.1, mostly of a clarification or correction nature. There are a few additional features that have no down-level counterparts in ODF v1.0.

A third OASIS Standard, ODF v1.2, is under development. The current drafts, using a very-different organization from v1.1, are available as pubic documents of the OASIS Open Document TC.

We can expect to see more versions of ODF and of OOXML at their various standards venues. We'll be watching here on nfoWorks as the situation becomes even more chaotic. Notice that this diversity ignores the variety of divergent implementations of the various specifications.

Format Versions that Live Forever

It is possible for one document-format specification to officially supplant another, with the older specification deprecated. That has not been done so far with any of the five-and-growing document-format specifications, any more than it has been done for most of the versions of HTML specifications that have been recommendations of the W3C (and IETF before the development track moved entirely to W3C).

For example, the last full-up specification for HTML, the HTML 4.01 W3C Recommendation of 24 December 1999, has this to say about its immediate predecessor: "This document obsoletes previous versions of HTML 4.0, although W3C will continue to make those specifications and their DTDs available at the W3C Web site." This was possible because HTML 4.0 was young and there were important defects that 4.01 cured.

The HTML 4.01 specification continues with the following recommendation: "W3C recommends that user agents and authors (and in particular, authoring tools) produce HTML 4.01 documents rather than HTML 4.0 documents. W3C recommends that authors produce HTML 4 documents instead of HTML 3.2 documents. For reasons of backward compatibility, W3C also recommends that tools interpreting HTML 4 continue to support HTML 3.2 [W3C Recommendation 14 January 1997] and HTML 2.0 [IETF rfc1866 November 1995 and the IETF-obsoleting rfc2854 June 2000] as well."

The XHTML branch of specifications, originally derived from HTML 4.01, were intended as the basis for a future generation.

Meanwhile, there has been work toward both XHTML 2 and HTML 5.0.

HTML 5.0 is currently intended to exist alongside XHTML 1.x and its newer arrangements while also absorbing XHTML 1.x to some degree (by having an XML form). The current HTML 5.0 draft specifies legacy processing (in its HTML-syntax form) for variations of over 60 HTML DOCTYPE DTD flavors, extending back to HTML 1.0 and other variants. The intention is to converge HTML and XHTML 1.x under a consistent HTML 5 processing model with only no-quirks, some-quirks, and quirks modes. This is also intended to end the variation and extension of HTML (not XHTML) by capturing <!DOCTYPE HTML> for its own and having a concrete HTML syntax that is fully-divorced from both SGML and XML. It is important to point out that HTML 5 is not going to eliminate the divergence that browser (user-agent) plug-in models, plug-in implementations and scripting systems (especially client side) bring to the mix.

Document-format versions are not easily abandoned. Even if production of a format is deprecated, consumption of the format may need to continue into the indefinite future, and certainly so long as emitters of deprecated formats have significant usage. The W3C progression of HTML is at a point where that is fully-recognized and being honored in reaching toward an HTML 5 plateau sometime in the next decade.

Considering this promising stabilization, when would I manage to change all of my web sites and blogs to clean HTML 5 pages? Not until I know that visits to those sites are only a small fraction of Internet Explorer versions prior to IE8 (or maybe IE9) and other browsers lacking full-up standards-mode processing. Fortunately, the HTML 5 specification-effort promises to show me exactly how to do that in a mechanical way. I am looking forward to automated assistance. In my case, I'll also have the benefit of my IE 8.0 mitigation effort. Other web sites may require other approaches, and user browser choice will involve important trade-offs for some time.

I am surprised by the number of people who operate multiple browsers. Although I operate multiple products for office applications these days, that's mostly to explore their interoperable use, not to ensure ability to interchange documents (well, not until I joined OASIS and the ODF TC). I've been a serial adopter of Internet Explorer versions since IE 2.0. As a typical late-adopter, I may finally branch out now just to have a better calibration of the migration to standards-based sites and browsers for them.

This is an important lesson for the management of the expanding variety of specifications of formats for office-application documents, formats of which HTML packagings are sometimes one of the flavors.

Reconciling office-application document-format versions does not promise to be so easy as the current effort to stabilize HTML for the web.

The Looseness of Document Specifications

Of course, OOXML and ODF are not close dialects off a single family tree, as HTML variants might be treated (and HTML 5 demonstrates, if successful). In addition, the current specifications are not for same-conformance, interchangeable-everywhere documents:

There are weak conformance requirements. It is not necessary to implement any particular amount of the specified format: OOXML or ODF. This is by design. I don't expect that to change. There is also no way to indicate how much or how little is accepted and/or produced. Well, you could look to see what software produced the document, using ODF as our example:

<office:document-meta
    xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0"
    xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0"
    office:version="1.2">
<office:meta>
    <meta:generator>
        OpenOffice.org/3.0_Beta$Win32 OpenOffice.org_project/300m3$Build-9328
    </meta:generator>
</office:meta>
</office:document-meta>

This strikes me as even less appealing than the challenge of sites adjusting for browsers and browsers adjusting to HTML DOCTYPE declarations (and their absence).

It is not encouraging that the office:version attribute and <meta:generator> element are both optional. It is unfortunate that the office:version attribute is generally uninformative about the processing requirements for the document file in hand, serving merely as an automatic claim of one specification the document conforms to. The document is also likely to conform to earlier versions and probably ~~alter~~ later versions, although it is unclear how we can determine that easily for a given document representation.

Arbitrary "foreign" elements are allowed. I'm not clear how IS 29500 for OOXML will allow for this kind of thing, but the ODF specifications are justly-notorious for this provision (ODF 1.1, section 1.5):

"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 shall read documents that are valid against the OpenDocument schema if all foreign elements and attributes are removed before validation takes place, or shall 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."

There are some further wrinkles and this proviso:

"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 shall be valid against the OpenDocument schema if the unknown element is replaced with its content only."

As a developer, I love gimmicks like this. But, basically, this only works with processors that re-encounter document files that they themselves produced. Anything more coherent requires that the implementers of different processors form some sort of out-of-band, separate-from-the-standard interoperability agreement on particular foreign elements and handling of office:process-content attributes. Users, confident that their software is "standard," will have frustrating and inexplicable interchange experiences (unless the usual thing is done and everyone agrees to lock in on the same software [version], surprise, surprise).
OOXML has a versioning scheme that might provide controlled extensions that degrade usefully when processed by implementations of down-level specification versions. It is unclear at this point whether this is just a more complicated way to end up with the same interoperability problems.
Some features require foreign content. Both OOXML and ODF have features where content is represented by a binary-data part elsewhere in the package. There is little (OOXML) or no (ODF) indication of what the format of the binary element is and what MIME types are allowed for such document components. All use of those features and any interchange agreements about them are beyond the current provisions of the relevant document-format standards.

There are other places where implementation-defined values are expected and are expected to be preserved by other implementations.
Some values and default selections are implementation-specific. I was mining in the ODF specification the other day. I did not expect to find attributes having text on these patterns:

"The value of this attribute is implementation [or application] specific."

"If this attribute is not present, the application might or might not display [whatever]."

These are relatively minor considering the amount of variability from the other conditions already mentioned. What's curious about these is the elevation of particular implementation-specific features as specification-favored. In the case of implementation-specific attribute values, there is also the interesting problem of a processor determining whether such a value is intended to have its implementation-specific interpretation or not. It appears that the related features will only be useful under tightly-restricted interchange conditions.

I will not be surprised to find similar looseness in the OOXML specification, IS 29500.

Prospects for Interoperable Convergence

We already have before us difficulties with interoperable convergence of individual progression of a single standard and its variety of implementation. This makes the prospect of harmonization between different standard formats rather murky.

Desktop office-application software has more promise with regard to application of Postel's Law, to be liberal in what is accepted and conservative in what is produced. Unfortunately, the current specifications do not require conservative, interoperable implementations; the current specifications are arguably antagonistic to such an achievement.

I suspect that this is an unintended consequence mixed with some inattention to what it takes for interoperability to be achievable.

It remains to see how our experience and understanding matures. We are at the beginning, not the finish. The journey may seem endless.

The process of IE 8.0 mitigation and preparation for a standards-mode approach to web browsing impacts this site and blog as well as every other web page I have ever posted (somewhere over 120MB worth and climbing).

I'm not going to say anything more about IE 8.0 mitigation and HTML harmonization here. The overall effort will be tracked in that category of Professor von Clueless posts; that's the place to follow along. The lesson for document interoperability is something that is definitely appropriate for Pursuing Harmony; there'll be much more to say about that.

... Tweaking the Sidebar ...

2008-08-19T20:39:00.001-07:00

Technorati Tags: nfoWorks, blogging, Blogger, web site construction

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.

Agreement on Document Rendering

2008-08-19T14:34:00.001-07:00

Technorati Tags: interoperability, document formats, document processing, Harmony Principles, presentation conformance, conformance, ISO/IEC 24754

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.

Interoperable ODF: Finding Ground Truth

2008-08-18T11:01:00.001-07:00

Technorati Tags: Jesper Lund Stocholm, ODF, OpenDocument Format, Microsoft Office 2007, Document Interoperability Initiative

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.

... Steady as She Goes ...

2008-08-17T10:13:00.001-07:00

Technorati Tags: nfoWorks, blogging, Blogger, web site construction

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).

Steady, steady ...

2008-08-16T12:16:00.001-07:00

Technorati Tags: nfoWorks, blogging, Blogger, web site construction

While I am preparing for major additions and starting my homework as a new OASIS Open individual member, I am also performing some simple maintenance to the site template (resulting in version 0.02):

There is one bit of client-side JavaScript at the bottom of the template that is completely extraneous. Instead of adding a link to the blog's main page from archive pages, I made all blog pages have links to the main page from the blog title. There is no longer any JavaScript.
There were some typos in my modified header that I cleaned up. These included a double-word occurrence of "Jason" and a missing ":" after a source-control label.
I moved the description to the sidebar in front of my profile.
I made everything below the profile on the sidebar right-justified, as is my general preference.
I removed the dummy links that were in the original template, leaving the Google one for now.
I moved the blogger badge and the information about the RSS feed to the sidebar also.

The new template previews correctly. Making this post will apply it to the main page, this individual post, and the archive page that this post is part of. Older posts have not been republished. They will continue to be formatted under the previous template, unless they are republished by me or as the result of a comment. I also backed up the blog to my development system before making the change on Blogger.

I believe there are extraneous cascading style-sheet (CSS) definitions in the <head> section of the template, and I will distill it down gradually. It is nice that there are no external style sheets, but I want to simplify what is sent to the browser even more.

The development of the fire drill and incident-handling materials is going to go slowly, and I will make more template changes when I need a respite from that and from content-creation activities.

IS 29500 (OOXML) Moving Ahead?

2008-08-15T09:29:00.001-07:00

Technorati Tags: OOXML, IS 29500, ISO/IEC JTC1 SC34, ODF-OOXML Harmonization, OpenDocument Format, OASIS ODF TC

OOXML Struggling Over the Last ISO Hurdle?

[a version of this entry appears on Professor von Clueless in the Blunder Dome]

Thanks to early word from Jerry Fishenden in the UK, we learn of today's press release in Geneva: The appeals to acceptance of DIS 29500 (Office Open XML Formats) are not sustained and preparation for publication of IS 29500 will proceed. There is one caveat, and that is the prospect of an appeal over the appeal resolution.

Meanwhile, DIS 29500 is now listed as deleted on the ISO site and we continue to wait for release of the IS 29500 documents to the public.

It is difficult to be excited about any of this absent availability of a specification to dig into. The maintenance process needs to get going and it would be really great if this situation were completely resolved, with publication of the edited IS 29500 specification, before the late-September ISO/IEC JTC1 SC34 meeting in Korea. The wheels of JTC1 turn slowly, with the best avenue for public input being the ECMA TC45 committee, where the gears also turn slowly and mostly invisibly. There needs to be greater transparency and public engagement, something that the federation system that funnels down into JTC1 SC34 does not support.

ODF as the Rôle Model

The situation for ISO/IEC IS 26300 (Open Document Format 1.0) is not particularly different, simply less encumbered at this point. Maintenance is at the OASIS Office Document TC. It seems unlikely that substantial work on ODF specifications will move elsewhere, given that this is where actual work is being done, unencumbered by multi-national hierarchic process and governance structures.

There are significant differences in transparency of OASIS maintenance in contrast with ECMA's record so far. There is a publicly-usable and visible comment list for submissions and public archives of the committee list and working documents, including a wiki that provides access to all proposals for the under-development ODF 1.2 specification. There is also an open discussion list for the proposal of an ODF Interoperability and Conformance TC. The public notice and review of that TC's chartering is expected soon.

Having joined OASIS as an individual, I expect to gain some very useful practice in anticipation of similar provisions for OOXML. In many ways, the division of my attention is going to be governed by where there is the least friction in the way of open discussion, non-duplication of effort (through knowing what comments there already are and knowing the views of others), and ability to review and make proposals. It will be unfortunate if the only open-to-the-public forum is a shadow created outside of any official OOXML maintenance bodies.

Helpful Harmony

The Harmony Principles and the development of nfoWorks appliances is different from the maintenance of either specification and the creation of any reference implementations and conformance/interoperability tools. But there are clear opportunities for some cross-fertilization. I will gear up for that in my usual pokey way.

Meanwhile, my attention is on the chartering of the ODF Interoperability and Conformance TC, the under-review errata for ODF 1.0, and, um ..., getting this blog in shape for easy, reliable use.

Weaving the Safety Net

2008-08-13T16:30:00.001-07:00

Technorati Tags: nfoWorks, blogging, Blogger, web site construction

The next series of activities for creation of this blog involve creation of a safety net against my own slip-ups and as a defense in case the blog becomes corrupted at some point.

This work takes up where Ramping Up has now left off. Compulsive knot-hole peepers will find a Construction Zone and Construction Notes on "Pursuing Harmony" Blog Operation.

1. First steps 2008-08-13T23:10Z. The first step is to capture the blog template and keep it in a form that is available under version control any time it is necessary to restore an earlier template:

I have switched from FTP to SFTP one more time, just to see if it is now working along with FTP (which took a while before it succeeded).
After accessing the Blogger dashboard for this blog, the original template is copied into the UTF-8 file default.htm.template.txt. That file is checked into the development folder for http://nfoWorks/diary and placed under version control there.
Once we have this much we are ready for the next step.

2. Template Cleanup 2008-08-14T00:11Z. The next step is to clean up the template a slight amount in preparation for further customization:

The SFTP transfer is definitely not working. I reverted to FTP from Blogger to the http://nfoWorks.com/diary directory on the hosted site.
The template is backed up. If viewed in a browser, it may render as HTML rather than as text. Using the browser feature for viewing the page's source code will reveal the coded-HTML of the template.
The template is edited to add the following features:
- A !DOCTYPE directive is added to the top of the template, specifying HTML 4.01 Transitional, the prevailing format on this site.
- An HTML comment with version-control label is embedded in the page.
- A comment with up-to-date revision history is added to the end of the file.
The text of the cleaned-up template is added to the Blogger account for use in all further posts (including the current version of this one).

3. Safety Net Incorporation 2008-08-13T01:23Z. With a maintainable template backed-up and versioned, there are many improvements called for. Those are cosmetic and not urgent, however desirable. Instead, provisions for locking down the blog, repairing/recovering it, and restoring it to operation will be put in place. The arrangement depends on the site being accessible by the administrator even though the blog is not working properly for some reason.

default.firedrill.htm is a replacement for the blog default page when a fire-drill is being carried out (such as one we will have shortly, much like a boat drill carried out before leaving port).
default.quarantine.htm is a replacement for any page that is effectively quarantined until a remedy is available in its place. This is typically done as a new version of a blog archive page rather than as a replacement for the default page, although anything is possible.
default.standby.htm is a replacement for the blog default page when the blog is made inaccessible for some reason. This is usually put up very quickly, without further details provided until later when there is some assessment of the situation.
harmony-atom.standby.xml is a substitute for the blog's harmony-atom.xml and rss.xml Atom feed files when there is need to quarantines until a problem can be resolved.
harmony-atom.testing.xml is a substitute for the two Atom feed files when the feed is blocked for a fire drill or other testing.

These pages are developed as part of the "Pursuing Harmony" Blog Operations material. That's the next step. Then we can have our first fire drill.

[update 2008-08-14T14:24Z added an important omitted word. I'm now back on the out-of-sight work needed in order to perform a successful fire drill. I forgot how tedious this is. The previous setup on Orcmid's Lair is old and stale and needs to be refreshed as part of that site's eventual repaving. Meanwhile, onward ... .]