Meta Meta Model

The XFeature tool supports editing of feature models but it does not enforce a particular feature meta-model. The feature meta-model is a user-defined configuration parameter of the XFeature tool. In practice, the feature meta-model is an XML Schema file that is loaded by the user when the tool is configured. In order to be understood by the tool, this user-defined feature meta-model has to comply with a certain structure. This structure is defined by a feature meta-meta-model. This page describes the feature meta-meta-model of the XFeature tool. It assumes the reader to be familiar with the description of the XFeature Tool Concept.

Meta-Meta-Model Implementation

The section 8 of the XFeature Tool Concept presented the feature meta-meta-model at concept level. This document discusses how this concept is actually implemented in the XFeature tool.

The purpose of the feature meta-meta-model is to encode the constraints on a feature meta-model that must be satisfied if the feature meta-model is to be handled and understood by the XFeature tool.

The feature meta-model is treated as an XML document that must be validated against a schema that encodes the XFeature-specific constraints. The validating schema is the feature meta-meta-model.

The feature meta-model is itself an XML Schema. It is therefore validated by default against the XMLSchema.xsd schema which is defined by the W3 Consortium and which defines the XSD language. The problem of creating a feature meta-meta-model can therefore be seen as the problem of creating a schema that incorporates the standard XMLSchema.xsd schema and adds to it the additional constraints imposed by the XFeature environment. This is illustrated in the next figure:


Figure 1: MetaMetaModel_1

The feature meta-meta-model must capture the conceptual structure for feature models described in section 8 of the XFeature Tool Concept (see in particular figure 8-1). According to this structure, a feature model consists of a tree of nodes of which one is the root node and the others are children of either the root node or of other nodes. Each node may have a set of properties attached to it and the properties are divided into sets of property sets. The nodes are characterized by a cardinality (which in turn consists of a minimum and maximum cardinality), and by a name.

The feature meta-meta-model assumes that a feature meta-model is encoded as an XML Schema and that each XML Schema element describes a feature model element. The possible feature model elements are: root node, node, cardinality, property set, and property. These feature elements are the elementary "building blocks" that the XFeature tool uses to build the visual representation of a feature model. The name of a node is the name of the XML Schema element that describes it.

The feature meta-meta-model must enforce three kinds of constraints on an XML Schema for that schema to be a valid representation of a feature meta-model:

  • The display type constraint
  • The structural constraints
  • The syntactical constraints

These three types of constraints are described in greater detail in the next sections. The immediately following section describes the implementation approach and explains how these three constraints are put together in a single schema for feature meta-models.

Implementation Approach

The feature meta-meta-model is implemented as an XML-based validating schema that implements all the constraints imposed by the standard XMLSchema.xsd schema and in addition implements the XFeature-specific constraints. The implementation of these additional constraints is done using the following two approaches:

  • Modification of the rules in the XMLSchema.xsd schema
  • Embedding within the XMLSchema.xsd schema of additional rules based on the Schematron schema language

In order to limit the changes to the XML Schema, the modification of the XMLSchema.xsd schema is done in a very limited manner. The changes to the XML Schema are minimized to keep the feature meta-meta-model itself a valid XML Schema. This is important to be able to use the feature meta-meta-model as an XML Schema in standard XML editing tools to provide code completion facilities that can help the user to construct his own feature meta-model.

The XMLSchema.xsd schema is modified using the "redefine" mechanism. A technical description of the "redefine" approach can be found here. Essentially, this mechanism is used to enforce a constraint that each XML Schema complex element should have a mandatory attribute called displayType taking one out of a finite range of possible values. This thus enforces the first of the three XFeature-specific constraints (see next section for more details).

A second mechanism is required to encode other two XFeature-specific constraints because the XML Schema is not powerful enough to express the structural and syntactical constraints. A more powerful schema language is required. The one that was selected is Schematron.

The Schematron schema language differs from most other XML schema languages in that it is a rule-based language that uses XPath expressions instead of grammars to express the constraints on the valid XML document. This means that instead of creating a grammar for an XML document a Schematron schema will make assertions applied to a specific context within the document. If the assertion fails, a diagnostic message that is supplied by the author of the schema is displayed.

Schematron has a further advantage in that it can be embedded into an XML Schema document. As a result, it is possible to combine the use of the redefine mechanism to specify the display type constraints and the Schematron checks to specify the structural and syntactical constraints on the XFeature meta-models in a single schema document. This single schema document is the XFeature meta-meta-model MetaMetaModel.xfmmm.

The XFeature tool provides scripts to check whether XML Schema complies with the XFeature-specific constraints defined in the meta-meta-model. If this check is passed, then the schema can be loaded into XFeature which will be able to treat it as a valid feature meta-model.

The MetaMetaModel.xfmmm is built as a new XML Schema whose target is the standard XML Schema namespace ( The top level schema element is defined as follows:

   xsi:schemaLocation=" XMLSchema.xsd"> 
      . . .

The following namespace declarations are used in the feature meta-meta-model:

xs namespace for XML Schema; the feature meta-meta-model is itself defined by the XML Schema
sch namespace for Schematron; Schematron rules are defined using specific Schematron elements that are defined in their own namespace
dm namespace for DisplayModel; the namespace is used to define the displayType attribute (see next section)
xsi namespace for XML Schema Instance; the schema instance location is specified in the xsi:schemaLocation attribute and is used to specify the physical location of the schema definition file

In the following three sections the content of the MetaMetaModel.xsd is described in relation to the XFeature-specific constraints as defined at the end of section Meta-Meta-Model Implementation. In each of the following sections one type of XFeature-specific constraint is described in greater detail.

The Display Type Constraint

The feature meta-meta-model assumes that each feature element is described by an XML Schema element. The possible feature elements are nodes, their cardinalities, their property sets, and the properties in a property set.

In the XFeature meta-meta-model, this link between XML Schema elements and the feature elements is enforced by stipulating that all XML Schema element types have a mandatory attribute representing the feature element which that schema element type describes. The name of this attribute is displayType. The feature meta-meta-model allows this attribute to have one of the following possible values:

  • none: this value indicates that the element is not displayed by the XFeature tool
  • cardinality: this value indicates that the element describes the cardinality of a node
  • node: this value indicates that the element describes a node
  • property: this value indicates that the element describes a property of a feature
  • propertySet: this value indicates that the element describes property set, namely a container for a set of properties for the same feature
  • root: this value indicates that the element describes the root node in a feature model

The displayType attribute is enforced by extending the XMLSchema.xsd through the xs:redefine element. Thus the XFeature meta-meta-model contains a redefine element that modifies the global complex type element of XMLSchema.xsd. The xs:complexType element of the XML Schema is extended with the dm:displayType attribute.

<xs:import namespace="" schemaLocation="DisplayType.xsd"/>
<xs:redefine schemaLocation="XMLSchema.xsd">
  <xs:complexType name="complexType">
      <xs:extension base="xs:complexType">
        <xs:attribute ref="dm:displayType" use="required"/>

The dm:displayType attribute is defined in a separate XML Schema file DisplayType.xsd. This file is imported to the XFeature meta-meta-model through the xs:import element. The displayType attribute is defined as an enumeration type with six possible values:


  <xs:attribute name="displayType">
      <xs:restriction base="xs:NMTOKEN">
       <xs:enumeration value="none"/>
       <xs:enumeration value="cardinality"/>
       <xs:enumeration value="node"/>
       <xs:enumeration value="property"/> 
       <xs:enumeration value="propertySet"/>
       <xs:enumeration value="root"/>

The display type attribute is defined in other namespace than XML Schema namespace ( Thus the XFeature meta-meta-model that contains the displayType attribute still has the structure of the XML Schema and therefore the standard XML parsers can be used to validate the structure of the feature meta-models. At the same time dm:displayType attribute is a part of the XML Schema definition and as such it is recognized by code completion modules of standard XML editors e.g. <oXygen>.

Note that the xs:redefine element allows the redefinition of the following four XML Schema elements only: xs:simpleType, xs:complexType, xs:group, and xs:attributeGroup. The xs:element element cannot be redefined. Since the feature meta-model elements are always defined as complex types, extension of the xs:complexType is functionally equivalent to the extension of the xs:element.

The Structural Constraints

The display type information discussed in the previous section allows the elements in the XML Schema to be mapped to the feature elements. The structural constraints defined in this section instead enforce the mutual relationships between these elements. More specifically, the following constraints are enforced:

  • element of displayType "node" can only contain elements of displayType "node", "propertySet", and "cardinality"
  • element of displayType "propertySet" can only contain elements of displayType "property"

The first constraint ensures that a feature model is built as a tree of nodes whereas the second constraint enforces the fact that properties are contained in property sets.

The feature meta-meta-model encodes the structural constraints as Schematron rules. The Schematron rules are embedded within the XML Schema using the XML Schema extension mechanism. This extension mechanism is based on the use of the annotation elements. Annotation elements can have two types of child elements, namely documentation and appinfo elements. The documentation element is mainly intended to provide humans with information about the schema while the appinfo element is intended for application-specific extension and is defined so that it can have any well-formed XML content from any namespace. Since a Schematron rules use XML syntax this is the place to embed rules from Schematron. Since almost all elements defined by the XML Schema specification can have the annotation child element, the most natural place to put the Schematron rules are on the element declaration where the Schematron rule applies. This solution has the advantage that the XML Schema element declaration and the Schematron rule that apply to the element are declared in the same place but it also has the drawback that it adds much code to the already verbose XML Schema. Hence, the feature meta-meta-model took an alternative approach where all the Schematron rules are included in the annotation element of the schema element itself.

<xs:schema . . . > 
         <!-- BEGIN OF SCHEMATRON PART -->
         <sch:ns uri="" prefix="dm"/>
         <sch:ns uri="" prefix="xs"/>
         <sch:pattern . . . />
         <sch:pattern . . . />
         <sch:pattern . . . />
         <!-- END OF SCHEMATRON PART -->

   <xs:import namespace="" schemaLocation="DisplayType.xsd"/>
   <xs:redefine schemaLocation="XMLSchema.xsd">
      . . .


This is illustrated in the code snip of MetaMetaModel.xfmmm. The xs:annotation element in the sample code is the first child node of the xs:schema element of the MetaMetaModel.xfmmm. It contains two types of Schematron elements: sch:ns and sch:pattern. The sch:ns elements are used to declare the namespaces used in the Schematron rules. The sch:pattern is a container element that encapsulate the Schematron rules.

Three Schematron rules are defined in the MetaMetaModel.xfmm. The first of them enforces the two structural constraints specified above. Other two enforces two syntactical constraints (defined in the next section).

The two structural constraints are enforced by Schematron pattern top-down_displayType_restriction. This pattern contains two rules. Each rule checks one of the structural constraints. First it defines the context node by evaluating an XPath expression specified as a context attribute of sch:rule element. Context node is an element of displayType "node" for the first structural constraint and an element of displayType "propertySet" for the second. After locating the context node the Schematron evaluates the XPath expression specified as a test attribute of the sch:assert element. The expression examines the display types of subelements of the context node. If the XPath expression evaluates to false an error message is printed.

The Syntactical Constraints

Feature meta-models are implemented as XML Schemas written in the XSD language. The meta-models are parsed and interpreted by the XFeature tool at run-time to decide what are the possible legal extensions of the feature model that is being currently edited. The XSD language can be very complex. In order to simplify the task of the XFeature tool, the XSD language is restricted by imposing certain syntactical constraints on the definition of the XML Schema that represents a feature meta-model. The following specific constraints are imposed:

  • Local complexType Definition Constraint: inheritance of complexType in the feature meta-model is not supported. This is achieved by forbidding global complexType definitions. As a result, a feature meta-model can only consist of global element definitions where each element is either of simple type or contains local complexType definitions.
  • Simple complexType Structure Constraint: it is not allowed to embed another complexType definition inside a complexType definition. If a complexType element contains elements that are of complexType then these elements may only contain references to globally defined elements.

The feature meta-meta-model encodes the syntactical constraints it imposes upon feature meta-models as Schematron rules using the technique described in the previous section.

The two syntactical constraints are enforced by Schematron patterns non-recursive_complexType and global_complexType. Each pattern contains one rule that checks the structural constraint. Schematron evaluates the XPath expression specified as a test attribute of the sch:assert element. If the XPath expression evaluates to false the error message is printed.

Context node for both rules is the root element of the feature meta-model. The pattern recursive_complexType checks the feature meta-model for occurences of xs:complexType element embedded in another xs:complexType element. It prints an error message if such a pair exists.
The pattern global_complexType checks the feature meta-model for occurences of global definition of complex type. It prints an error message if there is as a xs:complexType element in the root element of the feature meta-model.