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.

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

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

References:

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

[2] David Carlson: UML Profile for XML Schema, http://www.xmlmodeling.com/documentation/specs/

[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 primary goals for the next major revision (G4) of MMX Metadata Framework are:

• OMG MOF compliance, providing facilities to map metamodels created in MOF to MMX Data Model and realize those metamodels in MMX Repository;
• XML Schema compliance, providing methodology for realization of any metamodel expressed as an XML Schema;
• support for very basic workflow functionality directly in Core MMX Metamodel;
• inclusion of Dublin Core attributes and simplified RBAC support directly in MMX Core Metamodel.  

Changes from G3 to G4 in MMX Physical Data Model: 

Note 1. Enumerations are treated as Core Metamodel classes derived from DataType class and are realized on M2 level. EnumLiterals are realized as instances of one particular Enumeration class and are therefore stored on M1 level, ie. md_object.object_type_cd points to an object_type_cd on M2 level (md_object_type.object_type_cd).

Note 2. Core Metamodel provides very simple facilities to implement basic workflow functionality. These simple facilities come in form of state_ind, public_ind, mutable_ind and workflow_num fields of md_object table that, in combination with published_, edited_, created_ and changed_ timestamps are sufficient to handle basic workflow management needs. The details of a specific workflow implementation are left to an application developers.

Note 3. A simplified, 'low-calorie' RBAC implementation is part of Core Metamodel. User, Role and Permission are implemented as classes of RBAC metamodel. However, RBAC Object is realized as a property of a Permission object. This allows Permissions with multiple Objects, and both class-based (referring a class in M2) and object-based (referring a concrete object in M1) permissions are possible, even in mixed manner. Similarly, RBAC Operation is realized as a property of a Permission object, with enumerated value list stored in M1 as EnumLiterals. Again, interpretation of these Operation tokens is up to an application 'owning' those operations. Finally, in addition to standard RBAC features classes Privilege and Pattern provide additional functionality required to build easy-to-use permission management applications. Privilege acts as a template for Permission objects, Pattern as a template for Role objects.