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.


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