For instance, the OSType code inte indicates that the data was a four-byte signed integer in big-endian format.
The internal structure of these contain recursively-nested AEDescs, while the AERecord also associates each element with a unique record field ID, which is an OSType.
The Apple Event Manager also supports coercions, which converts AEDescs from one data type to another.
Unofficial bindings also exist for other languages (with varying degrees of limitation), including Perl, UserTalk, Ruby and Python.
The system was generally similar to the Document Object Model used in XML, although with some differences in access patterns.
The entire AppleEvent architecture identifies things using four-byte OSType codes, studiously avoiding actual words or phrases in English (or any other language).
An application may provide multiple 'aete' resources for multiple languages, in keeping with the original multilingual design of AppleScript itself For instance, consider the following AppleScript sequence controlling a fictional drawing application: This actually involves the sending of two AppleEvents to the target application (and the receipt of their corresponding replies): first, a get-data event is sent to retrieve the background color property of the window identified by the name "Old Drawing"; then a set-data event is sent to apply the value returned as the background color property of the window named "New Drawing".
This typically took the form of code for returning the "next" object of a particular type, allowing AppleScript to iterate over them.
By selecting a suitable set of suites, the developer could at least reduce the workload of planning how to expose their objects.
Yet because these objects were generally not part of the system itself (with the exception of the severely limited TextEdit editor), the actual implementation was left to the developer.
This makes implementation of the AEOM considerably easier, dramatically reducing the amount of code needed in the average application.
Additionally the majority of Cocoa applications are constructed primarily from Cocoa-standard objects, all of which were upgraded to offer fairly extensive scriptability.
A text file is used to map the internal "object-like" names onto human-readable versions, and in most cases creating this is all that is needed to add fairly substantial scriptability to most programs.