Halo didn’t initially work on my iBook G4; it would always quit just after showing the splash screen. After some weeks, Greg Grimes at MacSoft figured out that I should copy the “shaders” folder on the CD into the “Halo” ...

Without supporting documents, the range of values isn't known. For instance, the track ID is listed as an integer. Are negative IDs allowed? Is zero reserved? What about 1? What are the legal values for Genre (a "string")?

The domains from which values are chosen, and their semantics, aren't known. For instance, if playlists had IDs (and it's odd that they don't), could a playlist ID be the same as a track ID? I can think of plausible implementations which would prohibit this, as well as ones to allow it. For that matter, can a track number be greater than a track count in the same entry? (I have one CD with 12 "listed" tracks and a 13th "hidden" track....)

The semantics of XML elements aren't known, either. Is it legal to have a playlist with no tracks? What about a playlist in which a track appears more than once? What does it mean when a playlist has "All Items" set to false?

XML is just a way of writing an association list for people who can't follow LISP.

(Also worth noting, though a separate point, is that the iTunes XML representation is still missing a number of fields from the real library, such as equalizer settings.)

People have shown that this XML stuff _IS_ self documenting, because every tag has a name. Every one. Just in the way if you looked at a HTML page without knowing HTML, you can understand that the junk between the tags is going to be the page title, you can read XML.

Hmmm… somehow it's not intuitively obvious what this extract from my iTunes Music Library indicates:

<key>Smart Info</key>

<data>

AQEAAwAAAAIAAAAZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAA==

</data>

On the other hand, I tend to be slightly less enamoured of "open formats" than Matt's position in his column. I think there's a solution which is the best of both worlds: A documented file format, and a shared library to access it.

Documenting the file format means that it can be used on another platform, or after the original software has long since passed into oblivion. This is (almost self-evidently) a good thing.

What's not so obvious is that documenting the file format can also lead to stagnation. If Apple documents exactly what "Smart Criteria" is, and third party developers begin to rely on that, then Apple can't change this key because it would break third-party applications.

This is where having a shared library (a framework, for Mac OS X) comes into play. Third parties can use a well-defined API to access files; if Apple updates the file format, they can simply update the API as well. Applications may require updates to take advantage of new features, but they won't break if the file format changes. (The keychain is an example of how this can work well in practice.)

Providing a shared library allows applications to access files in a supported way; providing file format documentation allows developers on other platforms (or other OS versions) to read and write those files as well.

Building and testing a shared library is much more work, but it's likely that Apple's doing much of this anyway with iLife; hopefully they're not actually writing separate code for iPhoto, iDVD, etc. to access the iTunes library, for instance. Much of the additional work involved would be the documentation (which is, however, a lot of work).

Using reverse-engineered file formats is sometimes necessary, but it's always risky. Apple should not be encouraging developers down this path; it's bad for the developer, bad for Apple, and bad for the platform.

BTW, thanks for having the balls to leave a name and an email address or Web site.

Using XML doesn't make your file format open or readable. XML is a meta language. A file format based on XML isn't a priori any more open or readable than any other file format.

Potential employers? Get off your high horse man. You're wrong, you've been proven to be wrong, and you're going onward anyway. Get over yourself.

You've ignored nearly every point put forward, instead going back to assertions that your "new" definition of the word "can" is fine, that developers haven't done as I've suggested, and all sorts of things. You're relying on stories about astronauts and mythological stupid developers who can't write toolbox code. Hearsay won't win you points. You're still sitting squarely in the negative.

P.S. WTF does Cocoa have with your inability to realize that the <b> tag works fine. Nothing. Zip, zilch. It works fine, by the way.

P.P.S. Neener neener, now I have the last word.

Back in those days, toolbox dependencies were a bit tricky, and the tools had to be started in a certain order, not like today where the OS initializes everything for you (more RAM is a wonderful thing). The required order was carefully documented, but these developers had almost completely ignored it. By starting some tools before others they required were available, the entire system got confused.

One of our engineers spent some time on behalf of the developer and rewrote his toolbox initialization code, with all the calls and allocations in the right order. He plugged it into the developer's program, and like magic, every problem the developer had complained about went away. Every bug they had blamed on the toolbox just vanished when everything was done properly. So the engineer sent the code back to the developer with the assurance that this would fix every problem they'd reported.

The developer responded the next day: "Thanks, but we like the order we were starting the tools in. Please tell us how to fix the problems without changing the tool initialization order."

The moral of the story: if a programmer is bound and determined to believe something, no amount of logic will convince him otherwise. If you folks want to continue to believe that basing a product's main features on unsupported data structures is just fine because you are sure you understand every possible value and what it means, that's your choice.

It's also a red flag warning to anyone who's been involved in professional computing not to take your software seriously. How do you know to check for a "nil key" if you don't know if NIL is a legal value? How can you check against a DTD that doesn't exist? I see the versioning in AlbumData.xml -- what does it mean? Do you know that a change in the minor version means all the elements remain the same? What about a change in the application version? In the build number?

No, you don't know. You're guessing, and you're betting your users' productivity that it won't break. If you want to laugh at that, be my guest. You should just hope potential employers don't read you advocating it before any job interviews. I'm obviously not going to convince you that using undocumented and unsupported data structures is a bad idea, so have all the fun you want doing it. Just have the courtesy to tell your users what you're doing so they don't find out the hard way with iPhoto 3 or iTunes 4.

Steven: no one's saying that file formats don't change during development. They even change between versions. In fact, that's the entire point.

(By the way, although the comment system says the "b" tag is supported, it doesn't do anything; you have to type the much longer "strong" to get boldface. Gotta love the Cocoa way.)

And so the point is this: Apple may not be officially supporting these things, but it's perfectly within your grasp to use them. If Toast wanted to read your playlist, they could. That they don't is either a knock against them for laziness or proof that they don't want to.

Matt, your comparisons make no sense. How often, in the development of a piece of software (perhaps a less well planned one) does the file format change? I'd say fairly often. Developers can cope.

You're wrong about the XML DTDs and whatnot. You're wrong in assuming that'd "break" an app where any developer worth their salt would put in a check on a nil key or something. Have developers done this? No. Can they? You bet your ass they can. OmniGroup is. I have. Josh has. Others have too.

Part of my argument may be a semantic one, but your "space suit" argument really doesn't help your cause at all. It's a laughable analogy. And as for the insults, well, I'll continue to make mine blatant in favor of your backhanded "good luck with your semantic degree" variety.

Anyway, do yourself a favor and look at iPhoto's XML file. See the versioning? See the major/minor versions? I'll give you one thing: it's a bugger that this isn't "official" in some capacity, but guess what? Even if Apple published a spec there'd be nothing to stop them from upgrading the format or improving it in the future. It's published in a DTD'd XML format. That's as open as it needs to be to allow developers to work with it. Third-party developers have and will continue to do so.

You remain wrong, Matt. But hey, feel free to continue to delude yourself. After all, it's a free country.