This document describes the model representation language (MRL), the language used to specify Masermind models. The key concepts in this language are:
Direction, whose
values are Horizontal and
Vertical.
A model for a particular interface consists of instances of the classes defined in the Mastermind ontology. So, if you are an interface developer you never define new classes: you define instances of prototypes supplied in libraries. Mastermind provides a basic library of prototypes corresponding to the classes defined in the Mastermind ontology: for each class, there is one root prototype from which all other instances are made. In addition, Mastermind will provide more sophisticated libraries with more expensive reusable components.
Mastermind currently provides only a textual language for specifying models, i.e., for creating instances. We are currently constructing interactive tools for specifying models. When those tools become available, the textual language will be used only as a way to store the models constructed in the interactive tools. The textual language is called MTF for Model Textual Format. A small example of an MTF file for a toy interface is available in another document. More comprehensive examples include the specification of the presentation for a browser of Mastermind objects and other examples in the examples directory.
Before jumping into a more technical discussion of the key concepts, we will give you a brief overview of how these concepts are used to define the Mastermind ontology, i.e., the vocabulary for specifying models and how models are represented using this ontology. The Mastermind ontology consists of a set of class and enumeration specifications. The complete list of classes and enumerations is available in another document. Just to give you the flavor of what is there, there are classes to represent tasks, interaction techniques, presentations, guides, grids, colors, fonts, and application methods. Each class includes a complete specification of the set of attributes that instances of that class can have. For example, here is the specification of fonts:
A Font is used to represent a font for text objects. The attributes of fonts are:
The font class shown above has six attributes called available_styles, color, font, size, style and underline. The attribute available_styles is of type Font_Style, which is an enumeration. The attribute can store multiple values, and the values of this attribute are inherited from prototypes to instances.
Here are examples of two font specifications in the MTF syntax, the syntax for storing Mastermind model specifications in text files. The first one defines an object called Helvetica, which is a font. The Helvetica font is defined in the Mastermind library, and specifies all the attributes of the default Helvetica font.
Helvetica : Font {
available_styles = Bold, Italic, Bold_Italic, Regular;
color = Black;
font = "helvetica";
size = { units = Point; value = 12 };
style = Regular;
underline = None;
};
The following specification is typical of a font specification that would appear in the definition of a particular interface. It specifies a font object called Label_Font, which would presumably be used to specify the font for labels in a window. Label_Font inherits all the attributes from Helvetica, and overrides the specification of style to be Bold, and the size to be 14 points.
Label_Font : Helvetica {
style = Bold;
size = { units = Point; value = 14 };
};
Advanced. It is possible to extend the Mastermind model. If you are a researcher working on new interface development tools, then you might want to extend the Mastermind ontology by defining new classes and enumerations, or by adding more attributes to the existing classes. The details of how to do this are in section extending the Mastermind ontology.
A class defines the structure of a set of objects by defining all the attributes that the instances of the class can have. A class can be derived from another class, called its super-class. Instances of a class have all the attributes defined in its class, in addition to all the attributes defined in the super-class of its class, and the super-class of its super-class, and so on. Most of the interesting information about a class is contained in the specification of its attributes.
An attribute specification contains information about the type of value that can be stored in the attribute, the number of values that can be stored, how values of the attribute are inherited from prototypes to instances, and whether the values of the attributes participate in a part/whole hierarchy. These elements are explained in more detail below.
The type specifies the kind of value that can be stored in the attribute. The MRL system will ensure that only values of the specified type are stored in an attribute. The type of an attribute can be one of the following:
Attributes can store either a single value or a sequence of values. Attributes that can store multiple values have their type designated as Sequence<Type>. When an attribute is multi-valued the instances can hold zero or more values of the designated type.
SHOULD WE CHANGE THE DETAILED DOCUMENTATION TO USE Sequence<Type> OR SHOULD BE CHANGE THE TEXT HERE TO SAY multi_valued?
Caveat: in the current implementation of MRL if an attribute is multi-valued, there is no way to specify the minimum and maximum number of values that an attribute can have.
In general, classes are defined so that the values of attributes are inherited from prototypes to instances. MRL supports two kinds of prototype inheritance called is_like inheritance and plays_role inheritance. The rules for inheritance are quite complex and are discussed in a separate chapter on inheritance.
In MRL each attribute of a class can be independetly marked as inheritable, using either the is_like or plays_role keywords. If an attribute is marked with the is_like keyword then values of the attribute will be inherited according to the rules of is_like inheritance, and likewise, if it is marked with the plays_role the values will be inherited according to the rules of plays_role inheritance.
When the type of an attribute is another class, the attribute can be marked to be a "part", by using the part keyword. This makes the values the attribute define a part/whole hierarchy: the instance itself is the whole, and the values of the attributes are its parts. Of course, parts can themselves have parts, and so on. The part keyword affects the way in which instances of a prototype are created, and the way in which inheritance of values between the values of the part attribute can take place. The details are explained in the chapters on part/whole hierarchies and inheritance.
An enumeration defines a set of symbols that can be used as the values of attributes. When the type of an attribute is an enumeration, then only symbols defined in that enumeration are legal values for the attribute. Here is an example of an enumeration specification.
Font_Style specifies styles of a font used to display text.
As discussed in the the chapter about classes, a class defines the structure for all instances of the class. This means that all instances of the class have the same set of attributes. Of course, different instances typically have different values for their attributes.
When specifying models, you will never create instances directly from a class. MRL provides a much more convenient way for creating instances called prototype instantiation. To create an instance using prototype instantiation, you specify another instance as a prototype for the instance you want to create. Your new instance will inherit the values of all inheritable attributes from the prototype, so you don't need to specify them. Essentially, the inherited values act as defaults, so you don't need to specify them, but you can override them.
The example with the Helvetica font discussed above illustrates prototype instantiation. The instance called Helvetica is used as a prototype for creating the instance called Label_Font. Even though the specification of Label_Font does not explicitly provide values for attributes available_styles, color, font, style and underline, Label_Font does have values for these attributes because it inherits them from the instance called Helvetica. The reason that the values are inherited is that the attributes were marked as inheritable in the class Font. Note also that the specification of Label_Font specifies values for the style and size attributes, which override the values specified in Helvetica.
Caveat. It would be legal to specify the font attribute in Label_Font to be "times", in which case Label_Font would not be completely self consistent, because it would inherit from an instance called Helvetica, but it would represent a times font. Such specifications are syntactically legal in MRL. However, Mastermind provides model checkers that check models to spot inconsistencies of this nature to being them to your attention.
The rules for inheriting attribute values from prototypes to instances are quite complex, but in general you will not need to worry about them. If you are building interface models, the only thing that you typically need to know is whether an attribute is inherited or not, and you can easily find this out by browsing the class definition. The subtleties of the inheritance rules more directly impact developers of model-building tools and developers of run-time system services.
Part/whole hierarchies become an issue when the type of an attribute is another class. In this case the attribute can be marked as representing a part. This part marker affects the way in which values of the attribute are inherited down from prototypes to instances.
Suppose you have a prototye called P, and it has a part attribute called at, whose value is the instance A. If you create an instance of P called I, then the system will automatically use A as a prototype to help create an instance of it and store this new instance as the value of it in I. The new instance does not have an external name, but for the purposes of our discussion, let's suppose it is called B. So, if you ask for the value of attribute at in I, you don't get back A, you get B. Since B is an instance of A, it will inherit all the inheritable attributes of A.
In contrast, if attribute at had not be marked as part, then the system would not have created the instance of A. If you asked for the value of attribute at in I, the system would give you A.
For example, suppose a prototype dialogue box has a part attribute that stores instances corresponding to the OK and Cancel buttons. If you make an instance of this prototype, then the instance dialogue- box will have its own separate instances corresponding to the OK and Cancel buttons. You can modify the attributes of the OK and Cancel buttons in the instance dialogue-box without affecting the corresponding buttons in the prototype, and you can also modifiy the properties of the OK and Cancel buttons in the prototype dialogue-box and have the effects propagated to the buttons in the instance. The exact rules for how this happens have several subtleties that are explained in the chapter on inheritance.
In the font example shown above, the types of attributes color and size are classes, but they are not marked as part. This means that the values of these attributes are inherited as if they were primitive values. So, the color of Label_Font is Black, not an instance of Black. The consequences of this are subtle, but you as a designer of interfaces will probably not notice because the Mastermind ontology has been designed so that attributes are marked as parts when it makes sense in the context of interface design. One of the subtle consequences of not having defined color as a part attribute are illustrated by the following specification.
Label_Font : Helvetica {
style = Bold;
size = { units = Point; value = 14 };
color = { red = 0.2 };
};
The color of this font is the color defined by red = 0.2, green = 0 and blue = 0. If the attribute had been marked as part, the values for green and blue would have been the values defined for the color object in Helvetica.
The previous chapters give a high level overview of how inheritance between prototypes and instances works. The basic idea is that values of inherited attributes are propagated from prototypes to instances. In this chapter we give a detailed account of how inheritance works and of all the subtleties that arise when inheritance is combined with part/whole heirarchies and multi-valued attributes.
As mentioned before, MRL supports two kinds of inheritance, called is_like inheritance, and plays_role inheritance. These two kinds of inheritance will be described in this chapter.
In the following discussion we will suppose that P stands for a prototype, and that I stands for an instance of it.
The most basic rule of inheritance is the following:
Is_like inheritance refers to the inheritance rules that propagate values between prototypes and instances. The inheritance rules are divided into the following classes:
Here are the inheritance rules for single valued attributes that do not participate in part/whole heirarchies.
Suppose that P and I are of a class that defines two attributes
Suppose the P has the following values in its attributes. at_prim is set to the number 1, and at_cl is set to the instance called O1.
P at_prim = 1 at_cl = O1
When you create I as an instance of P then it will have the following values in its attributes:
I at_prim = 1 at_cl = O1
Suppose the following operations are applied to P, the prototype. We will use C++ notation to represent the operations, and we will explain what it all means so that this is understandable even if you don't program in C++:
If we apply the same operations to attribute at_cl, we obtain analogous inheritance results. The new value is inherited down to I.
Caveat for C++ programmers writing code in the model server: the syntax of the code in the model server is a bit different because there is no variable or #define called at_prim or at_cl. For each attribute in the ontology, Mastermind defines a variable called <ClassName>_<AttributeName>, so the real syntax would have to use the longer names My_Class_at_prim and My_Class_at_cl. The resaon for this is to be able to use the same attribute name in different classes.
In the case of multi-valued attributes there is an additional inheritance rule:
Here are some examples of how our P and I objects behave in the case that at_cl is multi-valued. Similar effects would result if at_prim was multivalued.
Here is the additional rule for single-valued attributes that participate in part/whole hierarchies. Note part/whole hierarchies are only relevant for attributes whose type is a class, so in our example we assume that the attribute at_cl is declared with the keyword part.
Our original example will now look like this. Suppose that P starts up with the following values
P at_prim = 1 at_cl = O1
When you create I as an instance of P then it will have the following values in its attributes. The value of at_cl is now M1, which is an instance of O1.
I at_prim = 1 at_cl = M1
Here are some examples of the effect of the inheritance rules:
The interesting thing to note is that since M1 is an instance of O1, then the is_like inheritance rules apply to it. So, if we change the value of an attribute in O1, it is inherited down to M1, the new instance. You can also go in and explicitly set the value of an attribute in M1, and then it will no longer be inherited from O1.
This instantiation behavior happens "all the way through" meaning that if some of the attributes of O1 are marked as parts, then correspondingly new instances will be created and stored in the corresponding attributes in M1, and so on.
The inheritance rules for multi-valued, part attributes are a combination of the multi-valued, no part rules, and the single-valued part rules. When values are added to the prototype, the corresponding instances of the values are added to the instance:
Advanced. There is one subtlety in rule 2: suppose that an instance M1 is explicitly added to I first, and then an instance O1 is added to P. How does the system know whether to inherit O1 down to I, or whether M1 actually shadows O1 so that O1 should not be inherited down to I? In cases like this one, when the relationship between the values is not explicit, the system uses the names of the parts to match them up. So, if M1 and O1 have the same name, then M1 shadows O1. Otherwise, the system constructs an instance of O1, and adds it to I.
Plays_role inheritance is an advanced feature that provides another way to inherit values between instances that do not participate in a prototype/instance relationship.
Plays_role inheritance is relevant only for part attributes, in both the single and multi-valued cases. Suppose that attribute at_cl is a multi-valued part attribute, and that P and I have the following values. I is an instance of P, and M1 and M2 are the instances of O1 and O2 that the inheritance mechanism created.
P at_cl = O1, O2 I at_cl = M1, M2
It is legal in MRL to change the prototype of an instance to be another instance of the same class. So, in particular, it is legal to change the prototype of M1 to be another instance R1 rather than O1. If this happened, all attributes of M1 marked with is_like inheritance will be inherited from R1, and not from O1.
However, the relationship between M1 and O1 is remembered by the system, and this relationship is called the plays_role relationship. We say that in object I, M1 plays the role that O1 has in P. This relationship is used by the system to maintain the inheritance even if the prototype of the inherited values is changed.
The idea of plays_role inheritance is to allow M1 to inherit some values from O1, even if M1's prototype is changed to R1. Every attribute of O1 that has the plays_role keyword will be inherited to M1, no matter what the prototype of M1 is. The values are inherited according to the rules of inheritance for is_like inheritance that were described in the previous chapter. The following restrictions apply:
To be provided in the next release of the documentation.