1. Sheet 1 DocEng’03, Grenoble, November 2003 Model Driven Architecture based XML Processing Ivan Kurtev, Klaas van den Berg University of Twente, the Netherlands

2. Sheet 2 DocEng’03, Grenoble, November 2003 Outline  Technologies for XML Processing;  Problem Statement;  Model Driven Architecture (MDA) Concepts;  MDA based XML Processing;  Example;  Transformation Language;  Conclusions;

3. Sheet 3 DocEng’03, Grenoble, November 2003 Context Applications written in an OO language  Main goal: transform a document into a set of application objects; Domain XML Document Application Objects Application Classes Transformation Encodes data from Implements concepts Instances The Transformation is a recurring task and requires automation

4. Sheet 4 DocEng’03, Grenoble, November 2003 Technologies for XML Processing XML Document Schema DOM Parser Processing Code DOM TreeApplication Objects  Generic interfaces to XML documents (e.g. DOM) Application Classes XML Document Objects Compilation Unmarshalling Instance of  Data Binding Tree traversing, class instantiation, type conversions are performed by processing code.  Compilation and Unmarshalling are automated;  Not applicable in case of dissimilarities between the schema and the application structure;

5. Sheet 5 DocEng’03, Grenoble, November 2003 Problem Statement  XML Processing:  Definition and execution of transformations between XML documents and application objects;  Requirements:  Transformations should be automated;  Transformations should produce the desired application objects;  Current technologies are either low-level or do not always produce the desired application objects;  More powerful transformation techniques are required!  Solution:  Application of Model Driven Architecture (MDA) model transformation techniques;

6. Sheet 6 DocEng’03, Grenoble, November 2003 Basic MDA Concepts  Model Transformations –The MDA Pattern (from “MDA Guide”):  Separation of system specification from system implementation;  Models:

7. Sheet 7 DocEng’03, Grenoble, November 2003 Meta Modeling and XML (1)  In the MDA models can be defined in the Meta Object Facility (MOF) based on four meta layers;  Similar meta layer organization is observed in the XML technology; Example:

8. Sheet 8 DocEng’03, Grenoble, November 2003  Schemas play the role of models for XML documents;  Schemas may be considered as MOF models if a proper Schema meta-model is defined; Example: In MOF Data Binding is a model transformation. Arbitrary transformation policies may be specified. Meta Modeling and XML (2)

9. Sheet 9 DocEng’03, Grenoble, November 2003 MDA based XML Processing  Document schema is a Source Model (at level M1);  Application Classes form a Target Model;  Transformations are specified between the source and the target model;  Transformations are executed over source XML documents and result in a set of target objects;

10. Sheet 10 DocEng’03, Grenoble, November 2003 XML Schema Meta-model Fragment of the XML Schema Meta-model (based on the W3C specification)

11. Sheet 11 DocEng’03, Grenoble, November 2003 Target Meta-model Constructs: Class, Attribute, Method, Generalization Fragment of the target meta-model (subset of UML meta-model)

12. Sheet 12 DocEng’03, Grenoble, November 2003 Example: Address and Person Source Schema Simplified version of the “canonical” PurchaseOrder schema from the XML Schema Primer: <element name="name“ type="string"/> <element name="street" type="string"/> <element name="zip " type="string"/> Application Classes (implemented in Java): public class Address{ public String street; } public class USAddress extends Address{ public String zip; } public class Person{ private Address address; public String firstName; public String lastName; public Person(Address address){... }

13. Sheet 13 DocEng’03, Grenoble, November 2003 Example: Target Model  The target model wraps the application Java classes  Deriving the target model from Java classes:  Java class to a model class;  Extension to generalization;  Public fields to attributes;  Constructor parameters to attributes;  Information not included in the target model:  Collections that implement multivalued attributes;  Access to the attributes;

14. Sheet 14 DocEng’03, Grenoble, November 2003 Example: Transformation Specification Transformation Language:  Abstract Syntax: MOF-based Transformation Meta-model ;  Concrete Syntax: specified as a grammar;  Two types of rules: Class and Attribute Rules; Class Rules: specify instantiations of classes in the target model based on selection of source components: personRule ClassRule source [ Address:CT/name:E ] target [ Person constructor {address} { firstName = getFirstName(source), lastName = getLastName(source) } ] Pattern Class to be instantiated Attribute to be set prior to the instantiation Attribute to be set after the instantiation Example:

15. Sheet 15 DocEng’03, Grenoble, November 2003 Example: Transformation Specification Attribute Rules: specify how the attribute values are obtained from the source. addressAttribute AttributeRule source [*:E] target [address] path=’parent::*’ An XPath navigation expression that locates the source nodes associated with the value Attribute to be set addressAttribute rule specifies how to locate the value of the address attribute: And the address object is created by another class rule: addressRule ClassRule source [ Address:CT ] target [ Address {street} ] Example:

16. Sheet 16 DocEng’03, Grenoble, November 2003 Adaptation to Java  Transformation language does not specify how objects are created and attributes are set;  In Java:  Object creation: constructor, factory method;  Attribute access: getter and setter methods, public fields;  Multivalued attributes: implemented as collections (array, Vector, etc.);  This is provided separately as additional meta information;

17. Sheet 17 DocEng’03, Grenoble, November 2003 Transformation Execution  There is no predefined execution order over the rules;  Implicit dependencies among the rules:  Constructor attributes are calculated before class instantiation;  Other attributes are set after the instantiation;  During execution the dependencies are resolved  Dependency graph is formed;  Execution order is determined after a topological sort over the dependency graph;  Circularity prevents the execution of the transformation;

18. Sheet 18 DocEng’03, Grenoble, November 2003 Conclusions  Approach for XML Processing:  Based on transformations between source schema and target application model;  Declarative language for defining transformations;  Based on the MDA/MOF technology;  Allows reuse of existing application classes;  A prototype of an interpreter that supports the core transformation language features is implemented;

19. Sheet 19 DocEng’03, Grenoble, November 2003 Future Work  Applying schema matching techniques for rule identification;  Generalizing the language to the arbitrary model-to-model transformations in the context of MOF;  Reuse and composition of transformations following the composition of the source XML schemas;  More efficient rule execution;