darcusblog

Awhile back I’d noted that Apple was adding ODF support to Leopard, but that it remained to be seen how good the support was. Well, at least one early report seems to suggest … pretty damn good. They do import/export (though still unclear how well), and it’s integrated into Cocoa and the new QuickLook previewer. So despite my general dislike of Apple’s incoherent stance on standards, here’s one place where they’re doing the right thing. Kudos to Apple, then.

If I had a suggestion for Apple for the future, I’d look into a way to bridge the new enhanced metadata support in ODF 1.2 with their CoreData framework. That way, Mac developers could easily embed richer intelligence into their documents using a W3C standard extensible metadata framework.

The new metadata system coming in OpenDocument 1.2 was the product of the ODF metadata subcommittee. Team member and proposal co-editor Svante Schubert from Sun discusses his excitement about the opportunities this presents for OpenOffice, as well as includes a link to a recent presentation he gave on the topic at OOoCon. Rob Weir from IBM follows up with more useful links and his typically smart perspective that shows both an understanding of big picture trends and possibilities, and technical perspective one would expect of an engineer. As he says of documents:

… for those who work with thoughts, the present constraints of encoding our knowledge as simple linear strings of Unicode characters is severe. In general text is multi-layered and hyper-linked in strange and marvelous ways. Your father’s word processor and word processor format are inadequate to the task. The concept of a document as being a single storage of data that lives in a single place, entire, self-contained and complete is nearing an end. A document is a stream, a thread in space and time, connected to other documents, containing other documents, contained in other documents, in multiple layers of meaning and in multiple dimensions. What we call a traditional document is really just a snapshot in time and space, a projection into print-ready output form, of what documents will soon become.

The enhanced metadata framework in ODF, suffice to say, should provide the technical basis for developers to explore these ideas, and to provide real benefit to their users. Indeed, another of our subcommittee members was a medical doctor and semantic web geek intensely interested in the thoroughly practical—in some cases life and death—possibilities associated with metadata enhanced patient records. What if, he asks, patient records were not just dumb text, but richly layered collections of structured data?

But the metadata system will also allow for more immediate pay-off, offering what most of us believe will be a superior solution for custom functionality such as fields. For example, we have included a generic metadata field. Just a simple container for generated text, both the field and whatever data gets associated with it will get described in RDF and serialized in the file package.

Unlike Microsoft’s custom schema support, we provide this through the standard model of RDF. What this means is that implementors can provide a generic metadata API in their applications, based on an open standard, most likely just using off-the-shelf code libraries.

But beyond the pay-off for developers, this will enable users and enterprises too. The standard model enables the seamless merging of disparate data; precisely the kind of technical requirements necessary to realize the kinds of dreams Rob and John outline.

Wow, things are certainly interesting on the productivity application front these days. Today I see news that Adobe is buying a really interesting —if currently flawed — new web application.

This screenshot shows both how beautiful the application is, and also how limited.

So it is definitely the most beautiful word-processor I’ve seen recently. It also supports ODF.

But … no styles support … at all! This is a worrying trend I’m seeing; reinvent tools for the 21st century by stepping back in time to the 1980s.

Alas, Buzzword is still in development, so I will hold out some hope that they can correct ship and implement elegant styles support before final rollout.

Oh, I would like to add that it’s really nice to see professional quality Adobe fonts like Minion and Myriad in Buzzword and the technically-similar presentation application SlideRocket rather than the absolutely atrocious Arial and Times we typically see. Kudos on that.

another update: So I got an account, and am playing with Buzzword. One word: wow! Also, they will be adding styles support; if it’s anything like the rest of the application, I’m sure they’ll do a good job with it.

IBM has released a free office suite based on OpenOffice called Symphony.

It seems they’ve done a nice job overall. The UI looks nice and clean and the website includes a list of easily accessible templates.

One problem with the UI, however, is its emphasis on presentational formatting. IBM is hardly unique here (Google Docs, for example, has no support for user-defined styles at all), but I’d like to think UI designers can do better.

Consider this screenshot:

Styles are present in the right-hand panel, but they are grouped within the local presentational styling section called “Font.” An average user will, not surprisingly, tend to fall back on the presentational attributes to get the formatting they want.

We know that semantic document authoring has all kinds of benefits; from easier document reuse and repurposing, to enhancing accessibility, and so forth. What if instead the panel had a top-level and more prominent “style” heading:

Style
-----
paragraph: ________
character: ________

Provide a wide-variety of excellent templates with a full gamut of possible (semantic) styles, make them available on the internet with previews and browseable from within the application, and users can instantly see benefits from this.

Obviously one needs to make it easy for users to quickly modify formatting, but must this require a “font” panel? Is there really not a better way?

Here’s a nice example from Apple’s Pages:

Styles are front and center in the UI, users can instantly see what they will look like when chosen, and each of them are about the meaning (heading, caption, etc.) of the content, rather than what it looks like (big, bold, etc.). I’d like to see something like this from the OpenOffice universe.

Thanks to Peter Sefton and his project for funding integration of Zotero with OpenOffice. Peter has more here. There’s still work to do all around:

• finishing ODF 1.2 for enhanced metadata and field support
• upgrading OOo to fully support ODF 1.2
• Zotero needs a much smarter scheme (using URIs) for identifying citations so that documents are portable

… but this is a great start.

Today the OASIS OpenDocument Technical Committee approved enhanced metadata support [pdf] for inclusion in ODF 1.2.

What do we mean by enhanced metadata support? We mean that you can:

• describe your document the way you want to describe it; no longer are you limited to a pre-selected list of properties
• describe different parts within your document: images, tables, paragraphs, and so forth
• tag pieces of document content as metadata; you can say this heading is a title, this fragment is the name of some person, and so forth
• create dynamic content fields based on this flexible metadata system

So how did we do this? What technology did we use?

At the heart the new metadata system is a standard model: RDF. We allow encoding of that model in two different ways; first, as RDF/XML graphs in the file package. Here developers can include custom metadata in the file package. They simply register their files in the new RDF-based metadata manifest, and they make it available for integration with the document.

Second, we also borrow some concepts from RDFa for in-content tagging. Elias Torres from IBM helped us greatly with figuring out how to elegantly knit RDF into ODF content, showing us along the way a very cool demo his team had put together in which they reworked OpenOffice Calc to store RDF natively. In this case every cell in the spreadsheet became layered with additional metadata, and the content could be mashed up dynamically with a Google map. The in-content metadata attributes will allow this sort of use case on top of existing spreadsheets, word-processing documents, and presentations.

RDF, then, provides a simple, extensible, and mixable data model. Using this model means not just that we provide extensibility within a particular domain (say bibliographic citations), but the ability to seamlessly blend and merge information across domains (say contact data and citations, image metadata and rights, etc., etc.).

All that remains if for developers to exploit the possibilities we’ve put in place. It will be interesting to see who implements it first. OpenOffice? KOffice? Google?

In comments to a post on an interesting interview with former Massachusetts IT official Louis Gutierrez, Kurt Cagle offers some sensible advice to Microsoft:

If Microsoft really wants to put together a superior product, then it should participate in the ODF standard for a 2.0 version that moves a little closer to its own perceived needs, recognize that their monopoly isn’t going to last much longer anyway if they are at a stage where they are losing customers because of their own inability to work with them on something as basic as interoperability, and compete on quality. I don’t think anyone - the ODF TC, the ISO standards committees, the customers - would seriously have any problem with that, and it would show that Microsoft recognizes that the world has moved away from where it was in 1997.

I see this idea to bring ODF and OOXML closer in line floated in some future ODF spec more and more, and it seems quite a sensible way forward. I would certainly welcome it, and while I cannot speak for the rest of the ODF TC, I wouldn’t be surprised if they felt likewise.

Elliot Kimber with a nice analysis of Adobe’s new Mars effort:

MARS is an XML-based format that is intended as a functional replacement for PDF…. After seeing Adobe’s presentation and talking to the guys from Adobe it’s clear that what they’ve done is a sincere and well-thought-out attempt to Do The Right Thing rather than a cynical recasting of proprietary stuff into markup so it’s “open.” MARS tries to use standards as much as it can and it seems to do so to a remarkable level of completeness. It uses SVG for representing each page, supports the usual standards for media objects (bitmaps, videos, etc.). Uses Zip for packaging, and so on.

I agree.

There are, however, two suggestions I have for Adobe. First, they should seriously consider using ODF to do the packaging. In fact, there’s already evidence they’ve thought of this. The last I looked, there was an ODF namespace in their manifest, even if it didn’t seem like it would validate against the ODF manifest schema per se. I’m sure the OASSIS ODF TC would be happy to discuss any changes they might need.

Likewise, this ties us back to the metadata question. It’s time for Adobe to seriously reevaluate XMP and move it from being an essentially proprietary subset of the RDF spec circa 2000, to reflecting a more open and more technically-refined and rich RDF of today. Think XMP NG, which is largely XML/RDF proper, plus conventions for embedding in (particularly binary) files.

Now that could be a really interesting combination!

Mathias Bauer—the new lead for OpenOffice’s Writer project—has an update on the application’s future. Particularly relevant for me and for people interested in the evolution of the bibliographic support in OOo is this comment:

As I mentioned our support to ODF: we are working on the integration of the changes from the ODF updates, we are already doing this for ODF 1.1. (mainly accessibility), but we will also work on ODF formulas and metadata once their specification has stabilized. Metadata will also become important for us as we will use them together with the Bibliography project to greatly enhance the citation functionality in OpenOffice.org.

Those of us working on the enhanced metadata support are quite excited by the possibilities it will open up for significant innovation in ODF-based applications. Because it will be standardized in the file format, those innovations can scale across applications. Indeed, a primary use case for the metadata support is a scenario in which two users collaborate on a document involving citations, but each uses a different word-processor and bibliographic database. But our requirements in turn will help drive a more general framework for both ODF and OOo.

In related news, Elias Torres from IBM is in the process of joining the ODF Metadata Subcommittee to use his wealth of experience with RDF and web applications to drive home the final proposal. He’s already added a lot to the discussion.