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.
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
XMLSchema.xsd schema and adds to it the additional constraints imposed
by the XFeature environment. This is illustrated in the next figure:
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:
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.
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:
XMLSchema.xsdschema 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.
XMLSchema.xsd schema is modified using the "redefine"
mechanism. A technical description of the "redefine" approach can be found
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
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.
MetaMetaModel.xfmmm is built as a new XML Schema whose
target is the standard XML Schema namespace (http://www.w3.org/2001/XMLSchema).
The top level schema element is defined as follows:
<xs:schema targetNamespace="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:sch="http://www.ascc.net/xml/schematron" xmlns:dm="http://www.pnp-software.com/fmt/displayModel" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/2001/XMLSchema XMLSchema.xsd"> . . . </xs:schema>
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
|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
In each of the following sections one type of XFeature-specific constraint is described in greater detail.
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
displayType attribute is enforced by extending the
XMLSchema.xsd through the
Thus the XFeature meta-meta-model contains a redefine element that
modifies the global complex type element of
xs:complexType element of the XML Schema is extended with the
<xs:import namespace="http://www.pnp-software.com/XFeature/displayModel" schemaLocation="DisplayType.xsd"/> <xs:redefine schemaLocation="XMLSchema.xsd"> <xs:complexType name="complexType"> <xs:complexContent> <xs:extension base="xs:complexType"> <xs:attribute ref="dm:displayType" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:redefine>
dm:displayType attribute is defined in a separate XML Schema
DisplayType.xsd. This file is imported to the XFeature
meta-meta-model through the
xs:import element. The
attribute is defined as an enumeration type with six possible values:
<xs:schema targetNamespace="http://www.pnp-software.com/XFeature/displayModel" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:attribute name="displayType"> <xs:simpleType> <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"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:schema>
The display type attribute is defined in other namespace than XML Schema
namespace (http://www.w3.org/2001/XMLSchema). Thus the XFeature
meta-meta-model that contains the
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.
Note that the
xs:redefine element allows
the redefinition of the following four XML Schema elements only:
xs:element element cannot be redefined.
Since the feature meta-model elements are always defined
as complex types, extension of the
is functionally equivalent to the extension of the
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:
node" can only contain elements of
propertySet", and "
propertySet" can only contain elements of
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
elements. Annotation elements can have two types of child elements, namely
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 . . . > <xs:annotation> <xs:appinfo> <!-- BEGIN OF SCHEMATRON PART --> <sch:ns uri="http://www.pnp-software.com/XFeature/displayModel" prefix="dm"/> <sch:ns uri="http://www.w3.org/2001/XMLSchema" prefix="xs"/> <sch:pattern . . . /> <sch:pattern . . . /> <sch:pattern . . . /> <!-- END OF SCHEMATRON PART --> </xs:appinfo> </xs:annotation> <xs:import namespace="http://www.pnp-software.com/XFeature/displayModel" schemaLocation="DisplayType.xsd"/> <xs:redefine schemaLocation="XMLSchema.xsd"> . . . </xs:redefine> </xs:schema>
This is illustrated in the code snip of
xs:annotation element in the sample code is the first child node of
xs:schema element of the
It contains two types of Schematron elements:
are used to declare the namespaces used in the Schematron rules.
sch:pattern is a container element that encapsulate
the Schematron rules.
Three Schematron rules are defined in the
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
Context node is an element of
node" for the first
structural constraint and an element of
propertySet" for the second.
After locating the context node the Schematron evaluates the XPath
expression specified as a
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.
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:
complexTypeDefinition Constraint: inheritance of
complexTypein the feature meta-model is not supported. This is achieved by forbidding global
complexTypedefinitions. 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
complexTypeStructure Constraint: it is not allowed to embed another
complexTypedefinition inside a
complexTypedefinition. If a
complexTypeelement contains elements that are of
complexTypethen 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
Each pattern contains one rule that checks the structural constraint.
Schematron evaluates the XPath expression specified as a
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.
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.
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
in the root element of the feature meta-model.