Metadata madness discussion continued

(in response to John Siracusa’s article http://arstechnica.com/staff/fatbits/2009/09/metadata-madness.ars)

I disagree with the plain correspondence of filetype to URI and creator code to bundle id, and I propose the file creator code was a somewhat overloaded in classic Mac OS. Clearly the creator code was used to control which application opened the file. Some complex or pro apps would have options that let the user specific what creator code to use when saving documents, and also there was a prevalence of expert utilities exposing creator codes to the user and allowing them to change it to customize what app to open the file with. That same functionality now has a easy built-in Open With interface that ends up placing an application’s bundle id into some metadata associated with the file.

But also, developers used to be encouraged to use generic filetypes like ‘TEXT’ or ‘JPEG’. I don’t remember if that encouragement was explicit or whether it was came about implicitly due to the unclear system around registering new file types. So in effect, the filetype was a generic type and creator code acted as a *subtype*. Look at any table of Mac OS file formats and they’ll be indexed by filetype + creator code combined (usually written like “tttt/cccc”).

To revisit one of John’s examples, a text file created by TeachText wasn’t just a text file, although it was compatible with any program that opened plain text files. It also contained a parallel set of data in the resource fork that defined the formatting and layout. The combination of the metadata “TEXT/ttxt”, described as a “TeachText document”, was the true definition of the file format. Bringing this example home, I recall there was a 3rd party program to made editing styled TeachText documents a little easier and I would use it to produce read me files. This program would have to *lie* when it wrote its files to say they were created by TeachText and not itself. If I had an unfinished read me file, I wouldn’t have been able to double-click it to open and continue working on it in the 3rd party program.

I can’t clearly remember many other clear examples of effective type/subtype, a common file type whose files were maybe compatible but not so useful across apps, but I think that’s because it was so long ago and I mainly lived in source code files, not too many documents. Can anyone back me on this?

The indication to the user was that there was a simple, smart system for identifying file types (after all the Finder would show a verbose description, not a 3-letter code!). Ask a user why Word would open when they double-clicked the file and they’d say because it was a Word file. Venturing into the realm of an MS Word document created by Word Perfect was something too subtle for normal users. UTIs far more closely match this model where a file’s type can more precisely describe specific formats and content, one app’s custom XML formatted text file can and should have a distinct UTI from another app’s sticky note text document. The hierarchical nature of UTI definitions allow the system to know that it’s still possible for the sticky note app to open that XML file if the user really wants (or better example, to receive a pasted snippet copied from the first app).

So I suggest the UTI corresponds to the file type + creator code (in subtype-sense), and system’s Open With metadata that corresponds to the creator code (in the, um, open with-sense). I’d say the type & creator is and always was flawed and the scheme in OS X is clearly much better … except for that nagging problem for old Mac diehards, that the only way to associate a UTI to a file is via the extension in the file name.

I totally agree with John that UTI metadata should get saved within files (technical: along with the hierarchical definition of the UTI for when taking the file to systems without the app), but instead I’d suggest letting the overloaded notion of the file creator die and stay dead. I think, though, when creating a file, applications should be permitted to set the Open With metadata to point to themselves if they know better than the system that the user is more likely to want that, ie. saving with a generic UTI for some reason, but expecting the user will want to reopen for editing. Or perhaps expose a standard control in the Save As dialog “always reopen the file with this application”, usually off , especially when exporting.

Metadata Madness Discussion