Being able to model the definition, access and creation of data is essential for a web application modelling language, and is the basis of all web modelling languages (termeddata-intensive modelling languagesby Ceri et al. [51]) such as WebML [50]. It is still debated whether programming languages should be typed; while they potentially increase the workload of a developer, a well-designed type system can capture many routine programming errors before the system is deployed [47].
A particular type system can possess a variety of features and designs; for example, the system can be typed or untyped; provide static, or dynamic type checking; and support safe or unsafe typing. These type system definitions are discussed in detail by Cardelli [47], and will be briefly summarised: • Dynamically checked language: “A language where good behaviour is enforced during execu-
tion.” This often means that an object can have many different types over its lifetime.
• Statically checked language: “A language where good behaviour is determined before execu- tion.” This often means that an object can only ever haveonetype.
• Typed language: “A language with an associated (static) type system, whether or not types are part of the syntax.”
• Strongly checked language: “A language where no forbidden errors can occur at run time (de- pending on the definition of forbidden error).” Strongly checked languages prevent the implicit conversion of one type instance to another.
• Weakly checked language: “A language that is statically checked but provides no clear guar- antee of absence of execution errors.” Weakly checked languages permit the implicit conversion of one type instance to another.
4.4.1 Primitive Types
In a type system, aprimitive typerefers to the smallest datatype that can be expressed, and may also be termed anatomic type[339]. In other words, the type can not be expressed as the composition or restriction of any other types in the type system5. These primitive types are often then used in the composition of more complex types, and instances are often immutable. Because they refer to the smallest expressible type of data, all languages which possess a type system will have at least one primitive type.
5This constraint is discussed in the XML Schema specification: “primitive datatypes are those that are not defined in terms of other datatypes; they existab initio” [339].
4.4 Type Systems 73
Figure 4.10: The built-in datatype hierarchy of XML Schema Datatypes, adapted from W3C Group [339]
4.4.2 Derived Types
Primitive types can be used to definederived typesthrough a number of mechanisms, including com- position, restriction, or extension. These mechanisms may be defined formally within the type system, allowing fortype reasoningto ensure the validity of the typed system [47]. General-purpose program- ming languages often support restriction-based derived types, such as subtyping in object-oriented languages; composition-based derived types, such astype unions, are less commonly supported. One notable exception is the Web Ontology Language (OWL), which also supports inferred types through class equivalence [351]. Derived types may be defined separately in type documents (for example, XML Schema) or directly in the system definition itself (for example, Java classes and interfaces).
One technology for representing type systems in XML documents isXML Schema[338]. XML Schema allows the formal definition of the syntax and semantics of a type system, which will be used to construct and verify instances of XML documents. This includes the definition of derived types based on existing types in XML Schema. For example, anemaildatatype can be naïvely defined as the composition of two strings,identifierandhost; i.e.,identifier@host6.
Figure 4.11: Representing XML Schema Datatypes within the metamodelling architecture of MDA using modelling spaces
XML Schema also defines the XML Schema Datatypes recommendation, which provides a hi- erarchy of built-in datatypes and derived datatypes through restrictions such as range bounding and regular expressions. This includes the definition of aur-type, which is a built-in datatype with “an unconstrained lexical space, and a value space consisting of the union of the value spaces of all the built-in primitive datatypes” (and their subsequent lists) [338]. The hierarchy of these datatypes is illustrated here in Figure4.10.
4.4.3 Type Systems in the Model Driven Architecture
Type systems can also be integrated into the metamodelling architecture of the MDA, as introduced earlier in Section3.1.5. The integration of type systems into the MDA specifically is not discussed in any existing standard, but it is fairly straightforward to adapt the metamodelling architecture of XML Schema Structure [338] and XML Schema Datatypes [339] in this way. The resulting architecture is summarised in Figure4.11.
In this architecture, a custom type schema is placed in the metamodel layer (M2), and instances of this schema are placed in the model layer (M1). The real world objects that the schema instance represents remain in M0. Importantly, the XML Schema datatypes are also part of the metamodel layer (M2), because the custom schema can refer to these datatypes. Custom datatypes as defined by the schema are also placed in M2. This is because these datatypes can be considered the metamodel for the actual datatype instances in M1.
The concept of modelling spaces [80] as discussed earlier in Section3.1.6can be applied to sim- plify the complexity of this architecture, and to aid in its comprehension. This allows the metamod- elling architecture to be split into the two modelling spaces of aStructure Spaceand aDatatype Space,