Prototyped data which is specified using only Basic and Operator TypeSpec's consist of a collection of data limbs. In contrast, a Tree Typespec specifies that the corresponding prototyped data is a ``normal'' MP tree (i.e., consists of node and annotation packets). A Tree Typespec is a useful means to indicate that the corresponding data trees have certain (most often syntactic) properties.
More precisly, a Tree TypeSpec is accomplished by a (Common) Meta Type which can be defined in any dictionary and which indicates that the corresponding prototyped data is communicated as an MP Tree that has a certain property, as defined in the respective dictionary.
The restriction to allow the data corresponding to a Tree TypeSpec to only consist of full node packets (of syntactically correct MP Trees) stems from the fact that we require MP data to always be parsable on a syntactic level. Only the data corresponding to the meta types defined in the prototype dictionary may be transmitted as data limbs.
Tree TypeSpec's can nevertheless be used to communicate the corresponding data objects more efficiently: First, we can attach annotations to the meta types at prototype specification time, which then apply to all instances of the corresponding node packets at data communication time; and, second, a receiver may use the additional provided syntactic meta information to parse incoming data more efficiently.
As an example, we show in table 9 the definition of Rational
and Integer common meta types, as done in the ``Numbers'' dictionary
(MP_Number).
The common meta types given in figure 9 can conveniently be used in a prototype tree to specify that the corresponding data are rational numbers. Furthermore, if they all have certain properties (such as being normalized), then we can attach this information as an annotation to the meta type in the prototype tree. The example in figure 10 shows how this mechanism is used to send an array of rationals. If a receiver ``knows'' what rational numbers are, then it could use compiled routines which read them more efficiently based on the prototype specification in line 1. Furthermore, if a receiving application requires all rational numbers to be internally stored as normalized numbers, then by means of the annotation in line 2, it does not need to normalize the rationals received.
