Building Adaptable and Reusable XML Applications with Model Transformations Ivan Kurtev, Klaas van den Berg Software Engineering Group University of Twente the Netherlands

Outline Context; Problems in XML Processing; Basic MDA Concepts; MDA-based XML Processing; Example; Conclusions and Future Work;

Context Application-specific XML processing: XML Document DOM Parser Processing Code DOM Tree Application Objects Mature tools and techniques for syntax definition and processing: XML Schema, Parsers, XPath, XSLT, XQuery; Application-specific processing: Processing code generates application objects; Difficult to standardize;

Problems in XML Processing Two Important Quality Properties of XML Applications: Adaptability: allows easy changes in applications; Reusability: processing logic should be reused in new applications Motivation: Hybrid languages (XHTML+Time, XHTML+SVG+MathML) and compound documents; Reuse of syntax is naturally followed by reuse of processing logic; Current techniques (DOM, SAX, Data Binding) do not provide the required quality properties; Processing logic is hard-coded in applications; Difficulties in reuse; Difficulties in changes;

Approach XML Processing based on Model Transformations (borrows techniques from Model Driven Architecture (MDA)); Transformation definition: relates an XML schema/DOM to a set of application classes; Transformation execution (processing): converts an XML document to a set of objects; Transformation definitions are expressed in a transformation language (e.g. MISTRAL);

Basic MDA Concepts Separation of system specification from system implementation; Increase in the level of abstraction for software development; Models: Model Transformations The MDA Pattern:

MOF and XML Meta Levels In the MDA, models are defined in an infrastructure known as Meta Object Facility (MOF) that spans four meta-levels; Similar meta-level organization is observed in the XML technology;

Transformation Pattern based on Meta Levels Refinement of the MDA transformation pattern:

Transformation Pattern for XML Processing Schema-less processing: based on DOM; Schema-based processing: an XML schema and DOM are available;

Structure of XML Applications Separation of concerns: Syntax (schema); Processing logic (transformation specification); Application classes (semantic domain);

Example (1) Processing of a subset of SMIL timing module; Source schema: <attribute name=’begin’ type=’string’/> <attribute name=’end’ type=’string’/> <attribute name=’dur’ type=’string’/> <attribute name=’timeContainer’ type=’string’/> Example of a timed document: <a timeContainer=’seq’ begin=’1’ dur=’20’> <b timeContainer=’par’ dur=’10’> <c timeContainer=’none’ dur=’10’/> <d timeContainer=’none’ dur=’10’/> </b> <e timeContainer=’none’ dur=’10’/> </a>

Example (2) Target Application Classes:

Example (3) Example time dependency graph as a result of timed document processing:

Example (4) transformation timeModule Transformation Specification written in MISTRAL: transformation timeModule languages MOF, Java timeApplicationModel instanceOf(MOF) JavaModel source timedXMLDocument instanceOf(MOF) XMLModel default target timeGraph instanceOf(Java) timeApplicationModel default timedElementMapping abstract ModelElementRule { source [e:Element link-to(node), condition {XPath($e[@timeContainer])} ] target [node: TimedElement {begin, end, dur, ctrlObject}] SlotRules { beginValue source [beg:Attribute=XPath($e/@begin)] target [begin=toInt(beg.value)] endValue source[end:Attribute=XPath($e/@end)] target [end=toInt(end.value)] durValue source [duration:Attribute=XPath($e/@dur)] target [dur=toInt(duration.value)] }

Example (5) Handling time containers and interval nodes: parallelContainer ModelElementRule inherits timedElementMapping { source [ condition {XPath($e[@timeContainer=’par’])} ] target [ node: Parallel {components} ] SlotRules { componentsValue source [timedChild:Element=XPath($e/*[@timeContainer])] target [components=target(timedChild, node)] } intervalNode ModelElementRule inherits timedElementMapping { source [ condition {XPath($e[@timeContainer=’none’])}] target [ node: Interval]

Reuse and Composition of Transformations A new language may be composed with the timing module: New processor is obtained via: Composing target application classes (software composition); Composing transformation definitions (based on the transformation language constructs);

Adaptability and Reusability Processing logic is explicit represented in transformation rules; Syntax, processing logic, and application classes are separated may evolve independently; Better granularity is achieved changes may be isolated to specific rules and classes; Reusability and Composability: Composition of software: difficult in the general case, aspect-oriented techniques may help; Composition of transformation definitions: easier since the transformation rules may be manipulated by other transformations;

Conclusions Approach for XML Processing: Based on transformations between source schema/document model and target application model; Uses transformation language MISTRAL 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;

Future Work Exploring the scalability of the approach; More complex case studies based on some WWW languages (e.g. SMIL, XHTML, MathML); Improving the transformation engine; Experiments with browser-like environments;