mmx metadata framework
...the DNA of your data
MMX metadata framework is a lightweight implementation of OMG Metadata Object Facility built on relational database technology. MMX framework
is based on three general concepts:
Metamodel | MMX Metamodel provides a storage mechanism for various knowledge models. The data model underlying the metadata framework is more abstract in nature than metadata models in general. The model consists of only a few abstract entities... see more.
Access layer | Object oriented methods can be exploited using inheritance to derive the whole data access layer from a small set of primitives created in SQL. MMX Metadata Framework provides several diverse methods of data access to fulfill different requirements... see more.
Generic transformation | A large part of relationships between different objects in metadata model are too complex to be described through simple static relations. Instead, universal data transformation concept is put to use enabling definition of transformations, mappings and transitions of any complexity... see more.

MMX Framework: Extending with Extended Properties

December 10, 2010 13:36 by mmx

Pretty often there is a need to add some extra attributes to a metamodel that has already been deployed. The need for those changes usually arises from changed requirements for an application. So how to enable those changes without extending the metamodel (M2 layer) itself?

There is a special property type, AnyProperty, to handle this scenario. Whan an object type (class) has a property of type AnyProperty, an object (instance of the class) can have an arbitrary number of different properties of type AnyProperty that all share the same property_type_cd. Then how to distinguish between those properties? 

All the instances of an AnyProperty descend from the same property type of a class in M2 layer, but an application who 'owns' them can give them new names. Alternatively, it is possible to use the same name, but a distinguishing prefix directly in the value field of the property. So an AnyProperty instance 'belongs' to an application and its completely up to the application how it chooses to use, denote and present this property.

Downsides (there obviously are some, right?). First, the inheritance mechanisms built into MMX Framework (MMXMD API) obviously cannot provide full support to those properties, as the names of them are not known to M2 layer. Second, AnyProperty is defined as String in M2 so an application cannot rely on the type information if it chooses to have an instance of AnyProperty that is implemented with some other datatype (eg. an XML document or a date formatted as a string).

Anyway, this mechanism (which bears some resemblance with anyAttribute element in XML Schema) enables making run-time changes in metamodel when design-time is not an option (run-time and design-time here refer to modeling, not application design), just remember to use it with care.


XML Schema to MMX Mapping: Essentials

August 16, 2010 17:54 by marx

XML Schema is an important and one of the most widely used modelling tools. Therefore it would make sense to have the the ability to use metamodels created as XML Schemas in MMX Metadata Framework in addition to metamodels originating from UML. As MMX architecture closely follows the ideas and architecture of MOF it would be natural to take advantage of the multitude of UML profiles for XML Schema that are already available. Most of these, however, focus on UML to XSD conversion, so there are only a few targeting XML Schema mapping to UML. As always, our approach is a pragmatic one, concentrating on elements we find more important, more widely used and easier to implement. Hence the word 'Essentials' in the title.  

Data types. Most important XML Schema built-in data types have direct equivalents in MMX Core Metamodel (string, integer, decimal, boolean, date etc.). A property (md_property_type) realizing an XSD attribute with built-in type therefore references one of these Core types in its datatype_cd. In case an XSD simple type is inherited from a built-in type with <restriction> construct the derived datatype is created in MMX M2 layer as a new class with datatype referred in <base=...> as its parent. The root data type classes have all required properties to support XML Schema restrictions and facets (length, minLength, maxLength, minInclusive, maxInclusive, minExclusive, maxExclusive, fractionDigits, totalDigits, pattern) that are appropriately inherited by their respective descendants as optional properties. In case a restriction specifes an enumeration a new Enumeration class is created.

Global vs. local. Global simple types would be realized as descendants of a built-in data type (parent_object_type_cd). Global complex types would be preferably realized as independent classes (md_object_type) with elements referring to them with <type=...> or <ref=...> implemented as their descendants. In case a complex type is defined directly inside an element (local complex type) it could be realized either globally and referenced with parent_object_type_cd, or directly inside the element, with parent_object_type_cd referencing the schema class. We assume that whenever an element references another element we can subsitute the reference with the referenced element. So, when there is a <ref=...> or a <type=...> attribute pointing to another (global) element we can replace the reference with the target element itself. The same applies to <attributeGroup>.

Naming. If possible, name attribute of an element or an attribute is used as name of a class (object_nm) or a property type (property_nm). It is very important that every element and attribute had either a name (preferred) or an ID (second best) to uniquely identify the corresponding class in MMX metamodel. In case both name and ID are missing a technical name gets generated that is less intuitive and makes the metamodel more difficult to understand. Note. origin_ds column of md_object_type is constructed based on either name or ID attribute.

Model Groups. XML Schema group (ordering) indicators <all>, <sequence> and <choice> do not have direct counterparts in UML. One way to implement this in MMX is via <group> (named model group) element. A <group> element would be realized as a class (md_object_type) having a 1:M relationship (aggregation) with the group members (classes). Ordering of the group members is indicated as a dedicated property of the group class.

XSD construct Mapping to MMX model

<schema> element corresponds to an MMX metamodel. <schema> attributes attributeFormDefault, elementFormDefault, blockDefault and finalDefault are irrelevant in MMX metamodel context and are assumed to have their respective default values. Content of targetNamespace attribute is stored with md_object_type (class) while version and xmlns attributes are stored as class properties in md_property_type. Each xmlns attribute gets its own property type as this is a multiple property type. 


In case an <element> contains a complexType, specifies a complexType as its type or references another element that happens to be a complexType it gets realized as a class (md_object_type). In case an element is a simpleType it is realized as a property (md_property_type) of the schema class. 


An <attibute> generally corresponds to an MMX M2 level property (md_property_type). default and fixed attributes values are stored in default_value_ds and changeable_ind columns of md_property_type. Required attribute (use="required") is stored in mandatory_ind column.

<complexType> <complexType> element is naturally realized as a class (md_object_type) in MMX. In case a complex type contains another complex type element, the nested element gets its own class and a relationship between the two classes. Complex type attributes are realized as properties (md_property_type) owned by the complex type class. 

Stand-alone (global) <simpleType> elements are realized as properties (md_property_type) of the root (schema) class.


MMX provides the facilities to realize an <enumeration> of unlimited depth in form of a special built-in data type. An enumeration class is realized in M2 (class) layer of MMX metametamodel. Enumeration instances (corresponding to enumeration literals of UML) are created on M1 (instance) layer, in md_object table. An attribute taking enumeration as its type is modelled as a property type with enumeration as its data type referencing the specific enumeration class as its domain_cd. 


A <group> is realized as a named class (md_object_type) having relationships with the group members. Order indicator (<all>, <sequence> or <choice>) is stored in a dedicated property of the <group> class.

<all>, <sequence>, <choice> 

XML Schema order indicators (<all>, <sequence>, <choice>) denote 1:M relationships (aggregations) that might require a specific order and are realized via a named <group> element.

<minOccurs>, <maxOccurs>

XML Schema occurrence indicators (<minOccurs>, <maxOccurs>) are expressed as a combination of mandatory_ind and multiplicity_ind columns. Note that mandatory_ind and multiplicity_ind do not support numeric occurrence indicator values therefore only values "0", "1" and "unbounded" are allowed here. 


An <attributeGroup> is essentially implemented as a complex type (MMX class), with attribute group name as the class name. A reference to an attribute group is realized either as inheritance between complex types or by substituting it with referenced attributes. In former case, the attribute group class would be an abstract class, with descendant class inheriting all of its attributes. 

<annotation>, <documentation>, <appInfo>

Class <annotation> is stored in object_ds column of a class (md_object_type). Attribute <annotation> is stored in property_ds column of a property (md_property_type). 

Notes. The following elements of XML Schema are not covered (yet) for various reasons:

- Identity constraints (<field>, <selector>, <key>, <keyref>, <unique>). 
- Undefined elements, attributes and content (<any>, <anyAttribute>, <notation>). 
- Relationships with external schemas (<redefine>, <import>, <include>). 
- Constructs we don't see too often or don't like (<union>, <list>). 

At least a part of this list will be covered in a subsequent release of this mapping document.


[1] Grady Booch, Magnus Christerson, Matthew Fuchs, Jari Koistinen: UML for XML Schema Mapping Specification 

[2] David Carlson: UML Profile for XML Schema,

[3] Martin Bernauer, Gerti Kappel, Gerhard Kramler: Representing XML Schema in UML - An UML Profile for XML Schema

[4] Nicholas Routledge, Linda Bird and Andrew Goodchild: UML and XML Schema

[5] M. Laura Caliusco, César Maidana, Martín Patiño, M. Rosa Galli and Omar Chiotti: A UML profile for XML Schema

[6] Martin Bernauer, Gerti Kappel, Gerhard Kramler: Representing XML Schema in UML – A Comparison of Approaches


The Quest for MOF Compliance

July 20, 2010 19:01 by marx

MMX Framework relies heavily on the concept of 'lightweight implementation of MOF'. This article will outline the mapping of MOF elements to MMX Framework classes and the principles of implementing MOF models in MMX Repository.

MMX Framework is NOT an academic undertaking run for purely scientific purposes in a closed lab on a desert island. It is being developed and maintained for practical purposes in a very pragmatic manner. Therefore reflecting every single MOF feature and artifact has not been a goal: it is designed with minimal overhead and minimal footprint in mind, hence the term lightweight. Also, MMX Framework is intended as a platform for metadata repository, therefore all behavioral aspects of MOF as well as the Factory Class have been deliberately omitted. Further, as the power of Complete MOF (CMOF) is not required for our purposes we restrict ourselves to the power and expressivness of Essential MOF (EMOF). So, for starters, here's a complete diagram covering EMOF:

M2 layer of MMX physical model consists of just three entities: MD_OBJECT_TYPE, MD_RELATION_TYPE and MD_PROPERTY_TYPE. The centerpiece of the model, MD_OBJECT_TYPE, maps to NamedElement concept of MOF 2.0 (ModelElement in MOF 1.4). Everything derived from NamedElement is mapped to one of the classes in MMX Core Metamodel. The following table lists all EMOF elements with their respective properties and how they are implemented and mapped against MMX data model. The mappings are presented in informal way and are expressed either as MMX data model objects (physical tables, columns) or as MMX Core Metamodel elements (classes, attributes).

EMOF MMX implementation Comments
Element Core::MMXClass For formal reasons, there's a root class that everything else descends from that corresponds to MOF Element.
Tag Core::Annotation Root level metaproperty (md_property_type) inherited by any MMX class.
+name md_property_type.property_type_nm  
+value md_property_type.default_value_ds   
NamedElement Core::<any class>  MOF Named Element is mapped to any class on MMX M2 layer 
+name md_object_type.object_nm   
Class  Core::<any class>   MOF Class is mapped to any class on MMX M2 layer 
+isAbstract  md_object_type.abstract_class_ind   
+ownedAttribute    Expressed through md_object_type - md_property_type relationship (1:N).
+superClass Core::SuperClass  Root level metarelation (md_relation_type) expressing containment, inherited by any pair of MMX classes 
+ownedOperation Not applicable   
Package  Core::Metamodel  Package denotes a namespace 
+uri md_object_type.reference_ds  Represents namespace URI 
+nestedPackage Core::SuperClass  nestedPackage/nestingPackage composition is expressed via a root-level metarelation applicable to any pair of MMX classes.
+nestingPackage Core::SuperClass see previous 
+ownedType  Not applicable  Expressed via MOF Type.package property 
Type  md_object_type.object_type_cd  Type is mapped via its subtypes (Class and DataType) 
+package  md_object_type.parent_object_type_cd  Package and Class are related via inheritance (parent-child) relationship 
TypedElement  Not applicable  TypedElement is mapped via its subtype, MultiplicityElement 
+type  md_property_type.data_type_cd This attribute is inherited and finally implemented by Property element 
MultiplicityElement  Not applicable MultiplicityElement is mapped via its subtype, Property. Other subtypes of MultiplicityElement (Operation and Parameter) are not implemented 
+isOrdered Not implemented yet   
+isUnique  Not implemented yet   
+lower  md.property_type.mandatory_ind  lower = 1 is expressed via mandatory_ind = TRUE. lower = 0 is expressed via mandatory_ind = FALSE
+upper md_property_type.multiplicity_ind  upper > 1 is expressed via multiplicity_ind = TRUE. upper = 1 is expressed via multiplicity_ind = FALSE 
Property  md_property_type   
+isReadOnly Not implemented yet   
+default  md_property_type.default_value_ds   
+isDerived  Not implemented yet   
+class  md_property_type.object_type_cd  Expressed through md_object_type - md_property_type relationship (1:N) 
+isID  Not applicable  Everything implemented in MMX data model always has a unique ID, this is built in 
+isComposite Not applicable  isComposite denotes hierarchical property. In MMX data model hierarchical properties are expressed via parent-child relations 
+opposite  Not applicable  opposite applies to MMX relationship types. Associations between MMX properties are not possible 
DataType  Core::DataType  MOF has 4 primitive types (Boolean, String, Integer and UnlimitedNatural) that are mirrored by corresponding MMX Core data types 
Enumeration  Core::DataType::Enumeration  Enumeration is a MMX Core data type
+ownedLiteral  Not applicable  Expressed via MOF EnumerationLiteral.enumeration property 
EnumerationLiteral  md_object domain value instances  EnumerationLiteral values are implemented as instances of their corresponding Enumeration class, on M1 level
+enumeration md_object.object_type_cd  Enumerations (Value domains) and EnumerationLiteral values (domain values) are associated via md_object.object_type_cd of instance records referring to their enumeration class record in md_object_type 
Factory Not applicable   
+package Not applicable   
Operation  Not applicable   
+ownedParameter  Not applicable   
+raisedException  Not applicable   
+class  Not applicable   
Parameter  Not applicable   
+operation  Not applicable   

Note. MMX (as well as EMOF) does not support visibilities. All property visibilities expressed in the UML MOF model are ignored and assumed to be public. 

The MOF specifies three capabilities that add-on to the modeling constructs from UML Infrastructure:

  • Reflection: Allows discovery and manipulation of metaobjects and metadata
  • Identifiers: Unambiguously distinguishes objects from each other
  • Extension: Allows dynamic annotation of model elements with additional information
As stated in MOF Specification: "In a MOF context, an object's class (i.e it’s metaobject) reveals the nature of the object - its kind, its features. The Reflection Package allows this discovery and manipulation of metaobjects and metadata." MMX supports Reflection through separation of M2 and M1 layers (Classes - Instances, Metaobjects - Objects) and instantiation association (via object_type_cd) between the two. Thus, manipulation and navigation of M1-level instance objects based on knowledge stored on M2 level is made possible.

"An element has an identifier in the context of an extent that distinguishes it unambiguously from other elements." MMX Framework is built on database technology so naturally everything in it has a unique key. Every element (class or instance) has actually two Identifiers: one in the form of a database table key, another as a unique URI. On M2 level the table key is a primary key column (SMALLINT) with unique values, and the URI is constructed based on the location of a class in the overall class hierarchy. On M1 level the table key is a primary key column (INTEGER), construction of the unique URI is the responsibility of an application that creates class instances.
"It is sometimes necessary to dynamically annotate model elements with additional, perhaps unanticipated, information." For dynamical annotation of models (Extension) Tag element of MOF is implemented as a top-level metaproperty of MMX root class. This property gets inherited by any MMX class and can be used to associate a collection of name-value pairs with model elements.