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.

The X Is For eXtensibility

September 11, 2011 19:24 by mmx

XDTL stands for eXtensible Data Transformation Language. Extensibility here means that new language elements can be easily added without having to make changes to XML schema defining the core XDTL language. These extensions can, for example, be coded in XDTL and stored as XDTL packages with task names identifying the extension elements. XDTL Runtime expects to find the extension element libraries in directories listed in extensions.path parameter in xdtlrt.xml configuration file: the pathlist is scanned sequentially until a task with a matching name is found. 

During package execution an extension is provided with a full copy of the current context. An extension gets access to every variable value that is present in the calling context, as well as its attribute values that get converted into variables with names of the attributes. From the extension's point of view all those values are 'read-write', but only those passed as variables retain their values after the extension element finishes. So, considering passing values to an extension, variables can be seen as 'globals' that return values and extension element attributes as 'locals' that get discarded.

XDTL syntax definition (XML schema) includes an any element that allows XDTL language to be extended with elements not specified directly in the schema. any element in XDTL is defined as

<xs:any namespace="##other" processContents="lax"/>

##other means that only elements from namespace other than the namespace of the parent element are allowed. In other words, when parser sees an unknown element it will not complain but assume that it could be defined in some other schema. This prevents ambiguity in XML Schema (Unique Particle Attribution). Setting processControl attribute of an any element to "lax" states that if that 'other' schema cannot be obtained, parser will not generate an error.


So how does this work? We assume that our main script is referencing an external XML schema, elements of which are qualified with prefix 'ext':


In this external schema a single element, "show" with attribute "text" is defined. Here are some examples of what works and what doesn't.

<ext:show text="sometext"/> works, as the external namespace with element "show" is referenced by the prefix 'ext'.

<show xmlns="" text="sometext"/> also works, as the namespace reference is 'embedded' in the "show" element.

<show text="sometext"/> does not validate, as the parser looks for element "show" in the current schema (error message Invalid content was found starting with element 'show' is produced).

<ext:show nottext="sometext"/> does not validate either (Attribute 'nottext' is not allowed to appear in element 'ext:show').

<ext:notshow text="sometext"/> validates but still does not work! As the processContents attribute of any element is "lax", although the element is not found the parser ignores this. However, the XDTL Runtime complains as it cannot find element definition in extension pathlist.


What if we would want to use extensions without XML schema accompanying it? For that we remove the reference to the external schema from the script header and run the examples once again.

<ext:show text="sometext"/> would not validate any more as the prefix 'ext' is not defined. The same applies to all the other examples with prefix in front of the extension element.

<show text="sometext"/> would not validate either as the parser looks for extension element in the current schema.

<show xmlns="" text="sometext"/>, however, validates and works! Although the parser cannot find the schema it does not complain due to "lax" processContents attribute. As long as XDTL Runtime is able to find the library package containing the extension in the pathlist everything is fine, otherwise it would give Command 'Extension' failed error.


So here's the summary. Extended elements (commands) can be well-defined (having their syntax definitions in form of an XML schema) or undefined (just the package, no XML schema), just as a transformation designer sees fit. In the former case, extended elements will be validated exactly as the core language elements would, in the latter case they will pass without validation. If an undefined and non-validated extension element is executed and does not match its invocation a run-time error would be generated.


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.