Re: [xml-dev] The illusion of simplicity and low cost in data designand computing
I'm glad someone mentioned the old days of Mac OS, when files had a "resource fork" and a "data fork", the former containing anything you might want to know about the bits in the latter. In practice, most people said it was painful and awkward, but I never went to the mat with it myself so can't relay the details.
Having said that, all the data you get over HTTP comes with a Content-type, a reasonably-well-structured but very brief assertion of how the byte payload is meant to be interpreted. This, in practice, seems to work pretty well. Suppose that back in the day, the resource fork had just had the equivalent of Content-type?
It is a shame Apple's Bento file format never took off. It combined the resource/data fork idea with an appendable archive.
I don't see any new contender: ZIP is still ascendant, Open Packaging Conventions have a too-complex simplest-case, and the package manager world is utterly siloed for each computer language.
So until then, pragmatics have to rule over elegant Separation of Concerns.
... On the other hand, it may be that where some existing successful technology clearly violates theoretical elegance and SOC, that theory may be wrong-headed or incomplete: it is a truth universally acknowledged that all systems that do work should not work. So perhaps the idea that the best place for the metadata of a file is IN the file (e.g. as magic number, as XML header, etc) not WITH the file, is not hacky but the most unified and best approach? (Just as the metadata for a MIME header is with the data, not a separate stream.)
Regards
Rick
