AppleScript_ The Definitive Guide - Matt Neuburg [41]
http://developer.apple.com/documentation/mac/IAC/IAC-308.html
In Xcode, to see a header file defining some relevant constants, choose File → Open Quickly and enter AEUserTermTypes.h.
An 'aete' resource may be static or dynamic . AppleScript can read a static 'aete' resource directly off the disk; but it has to ask the application for a dynamic 'aete' resource (which it does by sending the application an Apple event, of course), which means that the application must be running in order for its 'aete' resource to be read. The advantage of the dynamic approach is that the dictionary can be constructed in real time, in response to current circumstances.
The scriptSuite and scriptTerminology files
This pair of files are an innovation of Cocoa Scripting, a technology intended to allow a developer to write a scriptable application in Cocoa fairly easily. They are XML (property list) files with extensions .scriptSuite and .scriptTerminology. For information about their format, see:
http://developer.apple.com/documentation/Cocoa/Conceptual/Scriptability/Tasks/SuiteDefs.html
These files are not directly usable by AppleScript. Rather, the Cocoa engine translates them into a dynamic 'aete' resource when the application launches. Because of this, a Cocoa application that uses these files to implement its scriptability must be running in order for AppleScript to consult its dictionary; this is why certain applications are launched when you compile a script that targets them. For this reason, and because Cocoa's rendering of these files can result in a "substandard" 'aete' resource (Apple's word, not mine), some Cocoa applications include a static 'aete' resource as well.
The sdef file
An sdef (pronouned "ess-deaf") is an XML file expressing dictionary information. It was invented as part of Panther (Mac OS X 10.3); there, however, it could not be used directly as a dictionary. Instead, it was merely a convenient way to construct a dictionary; the sdef file had then to be translated into either or both of the other two formats by way of a provided tool called sdp .
On Tiger, things are greatly improved. First, the sdef specification has been changed in such a way as to allow it to express aspects of a dictionary that were impossible with the earlier sdef type, or even with an 'aete' resource. Second, a Cocoa application's sdef can be read directly by AppleScript. Thus, on Tiger, an sdef is a better dictionary—better than a dictionary has ever been before. The downside is that a Cocoa application that expresses its dictionary solely through a new-format sdef is scriptable only on Tiger. For more information, type man sdef in the Terminal. Chapter 27 contains an example of how to make a Cocoa application scriptable using an sdef.
Dictionary Troubles
A scriptable application's dictionary is exposed in human-readable form in a script editor application (see Figure 2-2). It may be said that nine-tenths of the art of programming with AppleScript is figuring out what a targeted application expects and permits you to say to it. You might think that this would be no art at all, since there's the dictionary giving you this information straight out. But it turns out that a dictionary is a remarkably poor device for communicating to a human user the information that is really needed. There are three main problems:
Because each scriptable application defines its own terminology, learning to script a new application sometimes feels like having to learn an entirely new version of the AppleScript language.
The dictionary is inadequate to express what the programmer needs to know in order to script the application successfully. Some of this inadequacy is due to poorly written dictionaries. Some of it is due to the inherent structure of all dictionaries, just as a mere list of vocabulary is insufficient for learning a human language. Some of it is due to the way dictionaries are displayed in a