Table of contents

1. Introduction

2. Goals

3. Concept summary

3.1. Operating environment handling

3.2. Workflow handling

3.3. Always open with

3.4. Next time open with

3.5. Suggested apps list

3.6. Interoperability subsets

3.7. Open in processing application

4. Conclusion

1. Introduction

We have been kicking around the problem of file type associations and OpenDocument ("ODF") files. Daniel had the wisdom to call for a cooling-off period because tempers (including my own) were starting to flare, for which I thank him. It was a good call.

From my perspective, the problem we face is that traditional operating environment file type associations and "open with" routines are inadequate solutions when multiple applications on the same system support the same file type. For example, an end user may wish to open one ODF text document in a file viewer, another in a word processor, another in a file version comparator, another in a desktop publishing system, another in an outliner, another in a web application's editor, another in a document manager, yet another in a file converter, another in a metadata stripper, on and on ad infinitum; furthermore, a user may want to open the same document in all of those application types at different times for different purposes.

If we do not solve this issue creatively, I foresee an OpenDocument future where the standard has little meaning. There is an enormous danger that if such issues are resolved by the development of application componentry frameworks designed specifically for applications that support OpenDocument, then we are right back on the path to giant stacks of applications built atop office suites using the latter's APIs to achieve integration. In a framework scenario, the pressure for supersets of the standard can only increase. I do not accept that we should accept that outcome without maximizing the ability of applications that support OpenDocument to function usefully without a componentry framework, or failing that with the minimal framework that is absolutely necessary.

Modifying current operating environment file type association schemes in a standardized way is not feasible because we have no control over their development and there are too many variants of such schemes. For such reasons and in light of our previous discussion, I believe we are in in agreement that any solution much more intelligent than default file associations requires more metadata than MIME types currently allow, short of unacceptably expanding the number of MIME types and/or file extensions used for the ODF standard; i.e., by further classifying application and file types. However, even were OASIS and ISO to approve more MIME types and file extensions, that still would do nothing for the situation when a user wishes to open the same document in different applications at different times. And that dilemma will be forced upon users increasingly often as more and more specialized types of applications support the OpenDocument standard.

In looking back at our discussion, I believe that my use cases were sound but my suggested solution was not. Please forgive me for being a bit thick-headed at times.

2. Goals

The following goals were used as guidelines in developing this suggested approach. The goals are synthesized from points that came up in our preceding discussion.

1. Require no changes in the implementing application's environment. The solution should not result in any error messages or loss of pre-existing functionality if any needed changes are not made to an ODF-supporting application's environment.
2. Minimize necessary user-initiated actions. A workable solution is intelligent enough to require no user intervention for the most common and important use cases but enables the user to take efficient corrective action if the automated processing does not produce the desired result.
3. Require no changes to documents generated before the solution is added to a system.
4. Allow for unpredictability in end user's adoption of software that implements the solution. A solution that requires the user to have installed only software that implements the solution is a bad solution. A mix of implementing and non-implementing software is a highly likely situation and may even be the norm until such time that the solution is near-universally implemented, if ever.
5. Allow for unpredictability in the number and types of specific applications supporting OpenDocument that may be present in the user's system.
6. Allow for unpredictability of the solution's implementation amongst developers of applications supporting the OpenDocument standard. Not all developers will implement the solution and amongst those who do, all implementations will not occur simultaneously.
7. Minimize the burden on developers who do implement the solution.

3. Concept summary

The concepts set out below attempts to accommodate each of the above goals. In summary, the approach encourages -- but does not require -- ODF-supporting application developers to implement four new metadata types. (The actual number of metadata types required may vary; however, four types are described for conceptual purposes.)

The approach assumes that clicking on an ODF file in a file manager's dialog or a file search engine's results screen triggers the environment to open the document in the application associated with that file's MIME or extension type ("file type association"). If the associated application does not support the new suggested metadata types, then the environment's file type association or "open with" routine is the end of the story and the user is left no worse off than before.

However, if the associated application does support the suggested new metadata types, then that application processes the metadata in the sequence given below until a match is found between an application present on the system and an application identified through processing the metadata. If such a match is found, the processing application launches the appropriate application to open the document and closes itself (unless the processing application is itself the application selected by processing the meta data. If no application is found in that processing, the file is opened by the supporting application that has the environment's file type association. The only change imposed on the user if there is no match is a slight delay in opening the document due to the time required to process the document for the presence of useful meta data. But if a match if found, the document is automatically opened in an application far more likely to be the one the user desires than is allowed by file type association schemes. So the over-all user experience is enhanced.

Caveat, the processing would not be fully automatic if the user is allowed to configure the processing application to open an application selection dialog upon finding empty or missing "Next Time Open With" or "Suggested Apps List" metadata. That option is suggested by a few of the use cases, but I will not dwell on that subject here.

The critical difference from what I proposed before and what I suggest now is that there is no software needed separate from an implementing application that supports ODF. The suggested solution can be implemented entirely within applications that support ODF but the solution does not require that it be implemented in all applications that support ODF. But the more applications that support the proposed solution the more useful the solution is to end users.

The metadata processing sequence described below would not, I think, be difficult for developers to implement, and the burden on developers could be further reduced by addition of pre-built meta data processors to development libraries.

The incentive for developers to support the suggested metadata types is simple: their app is far less useful to users if it does not support them. Applications that grab the relevant environmental file type associations and do not support the suggested meta data types will retain those file associations only so long as it takes a user to learn how to change those associations to an application that does support the solution and execute the change.

Before diving in, a further caveat; the following metadata type descriptions and use cases have rough edges aplenty and I have not described every conceivable use case. In particular, I have not considered in any depth the need for a system administrator to set permissions for editing any of the relevant metadata types, nor have I considered the use malware authors might make of the metadata types suggested. This document attempts to describe concepts and to illustrate possibilities rather than to define a standard. Please consider the suggestions in that light.

3.1. Operating environment handling

The process begins with a user-initiated action in the environment to open a document without any user action to specify the application to be used to open the document. The triggering action can be, inter alia, clicking on or otherwise selecting a document's name in a file management dialog or in a file search engine's query results dialog.

The environment: [i] identifies the document's MIME-type and/or file extension; [ii] compares that information to the environment's file type associations; [iii] if there is a match opens the document in the associated application; and [iv] if there is no match launches the environment's file Open With dialog.

The environment's processing of file type associations can include any changes to MIME types or file extension associations of the types discussed by Daniel and David, allowing an automated choice between an editor or a document viewer.

Next in process: The document is either opened by the application identified by the environment's file type association (if that application does not support the suggested meta data types) or the document's meta data is processed by an application that does support the suggested meta data types.

3.2. Workflow handling

This is a placeholder for some of the metadata types being developed by the OASIS ODF Metadata subcommittee. There may or may not be a need identified by the subcommittee for metadata specific to a workflow engine's scripts in a given document. However, if such a need is identified, I suspect that at least in some use cases such scripts should take precedence in automated processing of a document's metadata to select the application to open the document with.

For example, it may be desirable in many situations for a document to store internally some metadata regarding its state of processing in a workflow. E.g., a history of workflow steps completed, process scheduling information, whether metadata that should be stripped prior to publication has been stripped, a distribution list selection, user-initiated instructions for processing in the workflow, etc. (In a system that processes very large numbers of files, storing such metadata outside the document itself can present a major synchronization headache when recovering from corruption of the external metadata store. Fast recovery is facilitated by duplicating the processing metadata in the workflow application's data store and in the documents themselves. E.g., the workflow application could be designed to rebuild its external metadata store by batch processing all ODF documents in the system and recreating the external metadata store from the document metadata. This use case was being considered by the subcommittee; however, I do not know whether or what they have decided.)

1. Workflow handling use case 1. A user wishes her workflow engine to automatically determine what application should next open the document as determined by the presence or absence of automatically generated custom metadata indicating whether, inter alia, a document has been spell-checked since its last editing, has had specified metadata stripped in accordance with firm policy prior to publishing it to others, has been reviewed by all necessary co-workers, has been distributed, has had a corresponding calendar entry for follow-up generated, has been archived, etc.

If no match with an application on the system is identified processing metadata of this type, or if no metadata of this type exists, the processing continues to the Always Open With metadata type. Note, however, that a workflow engine's script might impose its own error handling routines at this point.

Notes

When considering these concepts, thought should be given to the potential need for network administrators to be able to set permissions for editing suggested metadata types. One potential solution is for such niceties to be handled by the workflow engine. I.e., a workflow script might be set to compare the metadata of this type to the same type at the time the document was received from another application or person in the workflow, and refuse to process the document with edited metadata of this type unless the user who edited the document has sufficient permissions.

As the first metadata type processed, this type could also conceivably be used in a non-closed system to store document-specific metadata reflecting a user decision to override all other metadata types in the app selection process. See the Next Time Open With metadata type.

Next in process: Error trapping and handling, then processing of Always Open With metadata.

3.3. Always open with

If there is no relevant Workflow handling metadata, the next metadata type processed is the Always Open With type. This is the "developer or publisher as dictator" metadata type.

1. Embedded system use case 1. A developer of an embedded system (such as the One Laptop Per Child Project's product) wishes to impose the requirement of opening a particular file with a particular application, with no option for end users to change the metadata. E.g., software documentation that can only be viewed; an ODF file used to store software settings.
2. Embedded system use case 2. A teacher or publisher of educational materials for educational institutions using an embedded system for students (such as OLTP) wishes to use an application supporting ODF in a general computing environment to generate or edit educational materials that can not be easily edited by users of a particular embedded software system. E.g., electronic school books and other class materials.
3. Encrypted files use case 1. A developer of an ODF-supporting application that encrypts files wishes to code his application so that ODF files encrypted by his application will always be opened by his application that stores and processes the necessary encryption keys. (Perhaps better implemented as a separate MIME-type for the encrypted document version.)
4. Digital Rights Management use case 1. A developer of an ODF viewer wishes to encode an ODF document's contents in such a manner that the document may be viewed only in the developer's viewer. (I'm not advocating such schemes, just acknowledging that they exist and there may be demand for such support in the processing for which app to use to open an ODF document.) (Perhaps better implemented as a separate MIME-type for the DRM document version.)
5. Custom ODF metadata use case 1. A developer has created an application that extends the ODF specification using custom metadata and there is a danger that data or metadata will be lost if the document is processed by a different application.
6. Custom ODF metadata extensions use case 2. Same as Custom ODF Metadata extensions use case 1 except that two developers' applications support the same custom metadata extensions set.
7. Pre-press documents use case 1. A developer wishes to provide end users the option of creating electronic documents that can not be edited by other users without being warned that the document should not normally be edited. (Think PDF-like pre-press documents here.)

If no match with an application is made processing metadata of this type, or if there is no metadata of this type, the processing continues to the Next Time Open With metadata type. But note that this metadata type might appropriately be the end of the processing road in a closed system like the OLPC project, if the suggested metadata types were implemented at all in such a project.

Notes

Any application that enables the end user to override the application selection set by this metadata type should by default display a suitable warning of potential data or formatting loss and require a decision by the user before allowing the user to save the file containing the edited metadata type in an application other than that specified by the Always Open With metadata. In a closed system, the developer may not wish to enable the users' disabling of the warning dialog. However, in a general computing environment the end user should have that option, subject to suitable permissions being granted by a system administrator.

However, it would be appropriate for applications that enable an end user to process a group of documents in batch mode to edit metadata of this type to present a single such warning dialog before processing the entire batch. For example, compare the two Custom ODF metadata use cases above and consider the situation when a second application becomes available that supports the same custom metadata set. In such cases, administrators or end users may wish to switch the relevant metadata en masse.

Next in process: Error trapping and handling, then processing of Next Time Open With metadata.

3.4. Next time open with

If Always Open With is where the developer or publisher is dictator, Next Time Open With is where the system administrator or end user reigns supreme (or not, in a closed system such as the OLPC).

1. Document opened by wrong application use case 1. A document has been opened by an application other than the application the user desires. The user has been forced to close the opening application, use the file manager's OpenWith feature, or open the desired application, activate its File Open dialog, navigate to the desired application, and manually open the document in the desired application. The user wishes to set the document so that the next time it is opened, it will open in the second application, using, e.g., a menu selection or dialog in the second application.
2. Final document use case 1. A user has created a document and all edits have been made. The user now wishes to set the document so it will be opened the next time by another application on her own or another co-worker's computer, e.g., in a specified document viewer for document review. (This is a scriptless, manual workflow use case of sorts.)
3. Selected app does not support relevant metadata types use case 1. The application selected for opening the document automatically does not implement the metadata types discussed herein and therefore includes no tools allowing the user to set that app as the opening app for the particular document. In such situations, the user desires the application associated with the file type to pop up a dialog allowing the user to set the metadata for the particular document before opening it in the desired, non-supporting application. (Not sure at all that this can be done without some modification of the environment, but I will mention it anyway. I have some ideas for work-arounds, but will save them for later.)
4. Application suggestion use case 1. A user setting a document to be opened by an application the next time wishes her application's relevant dialog by default to suggest itself as the application to open the document the next time so that she need only hit the Enter key if that is the choice she makes, without keyboarding text or manual selection of an application.
5. Application suggestion use case 2. Same as Application suggestion use case 1 except that the user wishes to set her application's relevant dialog to default to a different application to open the file the next time it is opened.
6. Application suggestion use case 3. A user creating a document template wishes all documents created from the template to be opened the next time by a particular application.
7. Anti-MIME type reprobate use case 1. A user with an ODF fetish has installed over 100 applications on his system that all support ODF text documents and templates. The user wishes to set the ODF editing application that has the environment's relevant file type associations so that it automatically inserts metadata causing the Next Time Open With dialog to launch anytime the user selects a file of those types in the user's file manager.

Next in process: Error trapping and handling, then processing of Suggested Apps List metadata.

3.5. Suggested apps list

This metadata type is primarily for: [i] those who publish documents for use by others to specify a list of appropriate applications with which to open the document; and [ii] those who wish to choose what application to open a particular document with from a list in a dialog.

No user warnings are required before editing this metadata type. However, Suggested Apps List metadata should not be removed or altered absent a specific user-initiated action. This is because if the second (recipient) user forwards the document to a third user whose system lacks the application specified by the second user in the Next Time Open With metadata, the first user's Suggested Apps List metadata could still provide an automated match with an application installed on the third user's system.

1. Document for publication use case 1. A user has created a document that will be posted to the Internet for downloading subject to a Creative Commons license allowing the creation of derivative works from images in the document. The user wishes to set metadata so that the document is likely to open in an appropriate ODF document viewer. The user believes that viewer applications A, B, and C that run respectively on operating systems X, Y, and Z each meet her criteria.
2. Document for publication use case 2. A user has created a document template that will be posted to the Internet for use by others in generating other documents. The template invokes word processor features found in only two word processors. The user wishes to have the document template open in one of those two word processors if either is present on the recipient's system. Query, might this use case be better handled under the Always Open With metadata type?
3. Disambiguation use case 1. A user sometimes needs to open a particular document in one application and sometimes in another, e.g., an editor and a viewer, or a simple outliner and a word processor that has a spellchecker. The user wishes a disambiguation dialog to appear after clicking on the document in her file manager allowing her to choose the opening application from a document-specific list of applications used to process the document.
4. Disambiguation use case 2. A user wishes to set a document so that he will always be presented with a dialog's list of applications with which he might open the document. The user is willing to maintain such a list manually using the application that has the file associations.
5. Disambiguation use case 3. Same as Disambiguation use case 2 except the user wishes to create and maintain multiple application selection lists and select among them from the dialog, e.g., one list for viewers, another for word processors, another for desktop publishing systems, another for writing tools such as a spellchecker, etc.

Next in process: Error checking and handling then processing of App Type to Open With metadata if implemented. Otherwise, the processing would not be invoked and the document would simply be opened in the app selected by the operating environment's file type association.

3.6. Interoperability subsets

This metadata type is used by implementing applications to identify documents conforming to: [i] interoperability subsets of the ODF standard formally declared in the standard; and [ii] interoperability subsets not formally declared in the standard but agreed to among developers of 2 or more applications that implement the agreed subset. (Latter particularly needs further evaluation.)

Each major document type in the OpenDocument standard (e.g., ODT, OTT) would be declared as the master set of all all tags specified therein. Subsets may be formally declared or informally agreed to for application interoperability purposes.

This should be the last metadata type processed. Otherwise, processing of the relevant metadata will not be consistent across all supporting applications and user decisions reflected by metadata choices made in other applications would be overridden. In other words, this is a placeholder for those who wish to play with custom metadata used to select which application opens a particular ODF document.

Next in process: Error trapping and handling, then Open in Processing Application.

3.7. Open in processing application

This is not a metadata type, but the ending event trigger for the processing flow embodied in the metadata processing. If no match is found between an app available in the environment and any identified in the metadata (or if enabled, as selected by the user in the Next Time Open With or Suggested Apps List dialogs), the ODF-supporting application processing the metadata opens the document itself.

Next in process: None unless error trapping is needed for some reason.

4. Conclusion

The scheme described above does impose a delay on the user by requiring the opening of two applications in cases where the processing application is not the application chosen by the automatic processing of the metadata. However, it is still a far faster process than manually closing the application that opened the document, opening the desired application, and using the desired application's File Open dialog to navigate to the document back to the document and open it (or than closing the app and opening the document using the environment's Open With dialog).

Under the current file type association scheme, that manual labor occurs over and over again unless the user decides to change the environment's file association for that file type, in which case the user encounters similar situations with the app that has lost the file type association. If forced into such manual steps, the proposed scheme allows a user to make a document specific setting so that the situation does not occur again for the same document.

Note that the scheme requires no changes to existing ODF documents. Users can use the suggested application features or not. But it at least enables a better experience with OpenDocument applications going forward. Should a user desire to make mass metadata changes in legacy documents, the generation of a script to batch process such files is no great mystery and applications could be created or adapted for such purposes.

The metadata processing approach envisioned also paves the way for software in the ODF application environment to more intelligently handle the opening of ODF files, providing the metadata required for that purpose. And I see no great tragedy if an operating system or file manager embraces and extends the scheme to offer even better handling.

I believe the suggested scheme meets each of the goals set out near the beginning of this missive other than the developer burden of implementation. The approach does impose some learning issues on users, but only to the extent they wish to use the "advanced" features of such a system. The approach also imposes some burdens on developers, but only if they regard the suggested changes as being worthy of implementation.

I do not suggest that implementing the suggested scheme should be required for compliance with the OpenDocument standard. I believe developers are in the best position to decide whether their apps should implement the suggested scheme. I see it as sufficient that there are strong incentives for them to do so. If adopted, any application that does not implement the suggested solution would be largely out of the competition for the operating environment's OpenDocument file type associations.