Managing XML documents with Epsilon

Introduction
Motivation
Background
Solution
Conclusions
.
.
. ..
.
.
A Lightweight Approach for Managing XML
Documents with MDE Languages
Dimitris Kolovos, Louis Rose, James Williams,
Nicholas Matragkas, and Richard Paige
Department of Computer Science, University of York
{dkolovos,louis,jw,nikos,paige}@cs.york.ac.uk
D. Kolovos et. al. | University of York | ECMFA 2012 MDE with plain XML documents - Slide 1/32

Introduction
Motivation
Background
Solution
Conclusions
.. Introduction
MDE is about automated processing of models
Model (in MDE) = any machine processable document that
contains (meta-)information of interest
Contemporary model management languages (M2M, M2T
etc.) mainly consider models captured atop 3-level
metamodelling architectures
MOF, EMF etc.
In this work we investigate the role of XML in MDE

Introduction
Motivation
Background
Solution
Conclusions
.. XML
.
Pros
..
.
. ..
.
.
Simple syntax
Plenty of tutorials, examples
No need for metamodelling (more agile)
No need for specialised tools: any text editor will do
Most developers already familiar with it
.
Cons
..
.
. ..
.
.
Verbose syntax
Only good for tree-based metadata, no support for types (by
default)
References/types are possible with XML Schema

Introduction
Motivation
Background
Solution
Conclusions
.. EMF vs. XML
XML is technically inferior to EMF
Plain XML is more agile than EMF
XML is immensely more popular
There is much potentially useful (meta-)information already
stored in XML

Introduction
Motivation
Background
Solution
Conclusions
.. Motivation
Enable agile MDE
Bring MDE to XML-literate developers without forcing them
to engage with metamodelling architectures
Lower the entry barrier by introducing one thing at a time
If MDE pays oﬀ, transition to a proper metamodelling
architecture should be less of an issue

Introduction
Motivation
Background
Solution
Conclusions
.. How?
Enable model management languages to manage schema-less
XML documents (playing the role of models)
To automate tasks such as model transformation, code
generation, model validation etc.

Introduction
Motivation
Background
Solution
Conclusions
.. Epsilon - www.eclipse.org/epsilon
A family of modelling technology-agnostic model management
languages for
Code generation (EGL)
Model transformation (ETL)
Model validation (EVL)
Model comparison (ECL)
...
All Epsilon languages reuse a common expression language
(Epsilon Object Language) and as such, they are consistent
and interoperable with each other

Introduction
Motivation
Background
Solution
Conclusions
.. Epsilon Model Connectivity
Epsilon Languages are decoupled from underlying modelling
technologies through the Epsilon Model Connectivity layer
Support for concrete modelling technologies can be
implemented in the form of EMC drivers
In this work we have implemented a new EMC driver for XML
documents
Epsilon Object Language (EOL)
Epsilon Model Connectivity (EMC)
EMF
(XMI 2.x)
MDR
(XMI 1.x)
Z (CZT) XML
Transformation
Language (ETL)
Validation
Language (EVL)
Migration Language (Flock)
Model-to-Text
Language (EGL)
Refactoring
Language (EWL)
Comparison
Language (ECL)
Merging
Language (EML)
Unit Testing Framework (EUnit)

Introduction
Motivation
Background
Solution
Conclusions
.. Attack Plan
...1 Introduce a small XML document
...2 Demonstrate how EOL can query/modify it through the new
XML driver
...3 Demonstrate how the XML driver is leveraged by task speciﬁc
languages
Epsilon Transformation Language (ETL)
Epsilon Validation Language (EVL)
Epsilon Generation Language (EGL)

Introduction
Motivation
Background
Solution
Conclusions
.. Example
<library>
<book title="Eclipse Modeling Project: A Domain-Specific
Language (DSL) Toolkit" pages="736">
<author>Richard Gronback</author>
<published>2009</published>
</book>
<book title="Official Eclipse 3.0 FAQs"
pages="432">
<author>John Arthorne</author>
<author>Chris Laffra</author>
<published>2004</published>
</book>
</library>

Introduction
Motivation
Background
Solution
Conclusions
.. Example (in Ecore)

Introduction
Motivation
Background
Solution
Conclusions
.. Working with Types in EMF
// Get all Book elements
var books = Book.all;
// Get a random book
var b = books.random();
// Check if b is a book
// Prints 'true'
b.isTypeOf(Book).println();
// Check if b is a library
// Prints 'false'
b.isTypeOf(Library).println();

Introduction
Motivation
Background
Solution
Conclusions
.. Emulating Types in XML
.
.
. ..
.
.
The t_ preﬁx before the name of a tag is used to emulate a
type, instances of which are all the elements with that tag.
// Get all <book> elements
var books = t_book.all;
var b = books.random();
// Check if b is a book
// Prints 'true'
b.isTypeOf(t_book).println();
// Check if b is a library
// Prints 'false'
b.isTypeOf(t_library).println();

Introduction
Motivation
Background
Solution
Conclusions
.. Getting and Setting Attribute Values in EMF
// Print all the titles of the books in the library
for (b in Book.all) {
b.title.println();
}
// Print the total number of pages of all books
var total = 0;
for (b in Book.all) {
total = total + b.pages;
}
total.print();

Introduction
Motivation
Background
Solution
Conclusions
.. Getting and Setting Attribute Values in XML
.
.
. ..
.
.
An attribute name, preﬁxed by a_, can be used as a property
of the element object.
The driver also supports the following preﬁxes: b_ for boolean,
s_ for string (alias of a_) and r_ for real values.
// Print all the titles of the books in the library
for (b in t_book.all) {
b.a_title.println();
}
// Print the total number of pages of all books
var total = 0;
for (b in t_book.all) {
total = total + b.i_pages;
}
total.print();

Introduction
Motivation
Background
Solution
Conclusions
.. Navigating References in EMF
var b = Book.all.random();
// Get its author
var authors = b.authors;
// Get its published element and print its text
b.published.year.println();

Introduction
Motivation
Background
Solution
Conclusions
.. Getting Child Elements by Tag Name in XML
.
.
. ..
.
.
The driver supports e_ and c_-preﬁxed shorthand properties
for accessing one or a collection of elements with the speciﬁed
name respectively.
e_ and c_ properties are read-only.
var b = t_book.all.random();
// Get its <author> children
var authors = b.c_author;
// Get its <published> child and print its text
b.e_published.text.println();

Introduction
Motivation
Background
Solution
Conclusions
.. Creating new Elements in EMF
// Check how many books are in the library
// Prints '2'
Book.all.size().println();
// Creates a new book element
var b = new Book;
// Check again
// Prints '3'
Book.all.size().println();

Introduction
Motivation
Background
Solution
Conclusions
.. Creating new Elements in XML
.
.
. ..
.
.
The standard new operator can be used to create new
elements in the XML document.
// Check how many <books> are in the library
// Prints '2'
t_book.all.size().println();
// Creates a new book element
var b = new t_book;
// Check again
// Prints '3'
t_book.all.size().println();

Introduction
Motivation
Background
Solution
Conclusions
.. Another example
<model>
<class name="Customer">
<property name="name" type="String"/>
<property name="address" type="Address"/>
</class>
<class name="Invoice">
<property name="serialNumber" type="String"/>
<property name="customer" type="Customer"/>
<property name="items" type="InvoiceItem"
many="true"/>
</class>
...
</model>

Introduction
Motivation
Background
Solution
Conclusions
.. Validation Constraints with EVL
.
.
. ..
.
.
Constraint that checks that the type of each property in the
XML model corresponds to a deﬁned type (class or datatype).
import "util.eol";
context t_property {
constraint TypeMustBeDefined {
check : typeForName(self.a_type).isDefined()
message : "Property " + self.a_name + " of class "
+ self.parentNode.a_name
+ " is of unknown type: " + self.a_type
}
}

Introduction
Motivation
Background
Solution
Conclusions
.. typeForName()
operation typeForName(type : String) {
return allTypes().selectOne(t|t.a_name = type);
}
operation allTypes() : List {
return XML!t_class.all.includingAll(XML!t_datatype.all);
}

Introduction
Motivation
Background
Solution
Conclusions
.. Model Transformation with ETL
.
.
. ..
.
.
Transformation that produces an EMF-based UML model
from the XML document.
import "util.eol";
rule t_model2Model
transform s : XML!t_model
to t : UML!Model {
t.packagedElement.addAll(s.children.equivalent());
}
(continued...)

Introduction
Motivation
Background
Solution
Conclusions
.. Model Transformation with ETL
rule t_class2Class
transform s : XML!t_class
to t : UML!Class {
t.name = s.a_name;
t.ownedAttribute.addAll(s.children.equivalent().
select(e|e.isTypeOf(UML!Property)));
}
...

Introduction
Motivation
Background
Solution
Conclusions
.. Case Study: MDE for EU Grant Proposals
.
Problem
..
.
. ..
.
.
Grant proposals contain signiﬁcant duplication
e.g. tables of eﬀort per work package, per partner, per activity
type
Figures can quickly become inconsistent across the proposal
.
Solution
..
.
. ..
.
.
Used XML to capture core information about the proposal
Work packages, partners, tasks, deliverables etc.
Developed a model-to-text transformation to generate all
required tables in the form of LATEX code from the XML
document

Introduction
Motivation
Background
Solution
Conclusions
.. Project data in XML
<wp title="Requirements and Use Cases" leader="TOG" type="RTD">
<effort partner="TOG" months="6"/>
<effort partner="YORK" months="6"/>
<effort partner="UDA" months="2"/>
<effort partner="CWI" months="5"/>
...
<effort partner="UI" months="3"/>
<task title="Use Case Analysis" start="1" end="6"
partners="*"/>
<task title="Technology Analysis" start="3" end="6"
partners="*"/>
<task title="Evaluation Planning" start="4" end="6"
partners="*"/>
<deliverable title="Project Requirements" due="6"
nature="R" dissemination="CO" partner="TOG"/>
<deliverable title="Evaluation Plan" due="6"
nature="R" dissemination="CO" partner="TOG"/>
</wp>

Introduction
Motivation
Background
Solution
Conclusions
.. EGL M2T Transformation

Introduction
Motivation
Background
Solution
Conclusions
.. Generated LaTeX
newcommand{workPackageOneEffortTable} {
begin{longtable} {|p{4.4cm}|p{2.8cm}|p{2.8cm}|p{2.8cm}|p{2.8cm}|}
caption{Effort table for WP1}
label{tab:workPackageOneEffortTable}hline
textbf{Work package} & 1 & multicolumn{2}{l|}{textbf{Start date
}} & 1 hline
textbf{Work package title} & multicolumn{4}{p{11.2cm}|}{
Requirements and Use Cases}hline
textbf{Activity type} & multicolumn{4}{l|}{RTD}hline
textbf{Participant name} & textbf{TOG} & YORK & CWI & UDA
hline
textbf{Person-months} & textbf{6} & 6 & 5 & 2 hline
textbf{Participant name} & UNIMAN & TEC & ST & UNINOVA hline
textbf{Person-months} & 2 & 4 & 6 & 4.5 hline
textbf{Participant name} & UI & & & hline
textbf{Person-months} & 3 & & & hline
end{longtable}

Introduction
Motivation
Background
Solution
Conclusions
.. Rendered Table318736 OSSMETER
A6. Work Package Descriptions
A6.1. WP1: Requirements and Use Cases
Table 4: E↵ort table for WP1
Work package 1 Start date 1
Work package title Requirements and Use Cases
Activity type RTD
Participant name TOG YORK CWI UDA
Person-months 6 6 5 2
Participant name UNIMAN TEC ST UNINOVA
Person-months 2 4 6 4.5
Participant name UI
Person-months 3
Objectives:
Within this workpackage the requirements will be defined for the new open source analysis tools,
technologies and processes to assist European software developers and decision makers, which are
driven from both an industry and technology perspective.
The use cases provided by the industrial user partners in the project will be analysed and industry
driven requirements for the project will be defined and prioritised. The technology partners will
further detail technical requirements that address the industrial user needs within the use cases and
fulfill the technological breakthroughs targeted by the project. Requirements will be established for

Introduction
Motivation
Background
Solution
Conclusions
.. Observations
XML’s agility makes it ideal for quick prototyping
No need to design a metamodel ﬁrst
Model evolution is easy
Model management code is more verbose with plain XML
models
e_, c_, a_, t_ preﬁxes
Programmatic not-containment reference resolution
Referential integrity must be validated programmatically
Increasing motivation to move to a proper modelling
framework as the metamodel stabilises and complexity
increases
Migration to EMF is manual (so far) but straightforward

Introduction
Motivation
Background
Solution
Conclusions
.. Summary
Presented a new driver for Epsilon that enables plain XML
documents to be managed as models
The proposed approach aims at lowering the MDE entrance
barrier for XML-literate developers, and at enabling agile MDE
Sub-optimal MDE is better than no MDE

Introduction
Motivation
Background
Solution
Conclusions
.. Download
Available at http://www.eclipse.org/epsilon/download

Managing XML documents with Epsilon

More Related Content

Viewers also liked

Similar to Managing XML documents with Epsilon

More from Dimitris Kolovos

Recently uploaded

Managing XML documents with Epsilon