2. Foundations and State-of-the-Art

This chapter gives an overview of the technologies used in this report, as far as necessary for understanding.

2.1 XML Query Languages

XML is becoming the method of choice for representing structured information in a formalized way. However, it needs a convenient way to query and manipulate XML structures. It needs an equivalent to SQL.

2.1.1 Overview of proposals

Several XML query languages have been proposed. I will give a short overview of some proposals and their relation to this paper.

XML-QL.

XML-QL was designed at AT&T Labs. It's an extension of SQL with an additional CONSTRUCT clause for generating XML fragments. The current specification is available at [XMLQL]. XML-QL was the first language I examined. I found some serious lack of expressive power, which is described in chapter 4.

XSLT.

XSLT is a proposal of the W3C available at [XSLT]. It's intended to translate arbitrary XML documents into Formatting Objects, a special XML instance designed to be rendered on screen. With XSLT I was able to solve the problems encountered on XML-QL. See chapter 5 for details.

XQL.

According to [BC99], XQL is an extension to XSL pattern syntax, with a reduced expressive power. Therefore I didn't evaluate XQL any further. A draft is available at [XQL].

2.1.2 Requirements

[BC99] lists a comprehensive set of requirements for query languages. This section outlines the requirements I found being related to this paper.

2.1.2.0.1 Joins.

A join compares two or more XML attributes or data. A typical comparison is the equality. [BC99] points out, that XML-QL supports joins, while XSLT does not. In this paper the join of XML-QL is solely used for the quite unsatisfying implementation of the transitive closure (see section 4.2). XSLT solves this problem much better with recursion.

2.1.2.0.2 Matching of partially specified expressions with cyclic data.

With cyclic data it is possible to run the query processor into an infinite loop. This criterion examines, whether the language processor must detect such a situation and abort gracefully. [BC99] correctly points out, that XSLT does not support such a detection. This is concerns the script in A.3. If the generalization relation contains a cycle, this causes the script to loop infinitely. The XML-QL specification leaves this property unspecified.

2.1.2.0.3 Querying the instance order.

Querying for XML elements appearing in a given order in the document. [BC99] claims, that XML-QL cannot do that. However, I found a construction suitable for this, as explained in 4.1, although this is not implemented in the prototype. XSLT and its prototype LotusXSL support instance order.

2.2 XML Metadata Interchange (XMI)

Roughly speaking, XMI is a XML representation for UML. But the details are a bit more complex:

Meta Object Facility (MOF).

MOF is a standard for describing meta information. In contrast to UML it is much simpler. However, UML is described in MOF, so UML is a special MOF instance. This makes it possible to describe UML with MOF formally, which is quite smart.

XML Metadata Interchange (XMI).

XMI is a method to represent a MOF instance in XML. Since UML is a (the) instance of MOF, XMI is a (the) method to represent UML in XML.

However, the concept has some drawbacks. The definition of XMI designed for more than just UML, it's designed for any meta model, which can be described in MOF. This makes XMI more complex. A XML representation especially for UML could be simpler, easier to read for humans and less tedious to parse.

Let me explain this on an example. Given the task to represent an operation with its parameters in XML, most results would probably look like this:

<Operation>
  <Parameter>...</Parameter>
  <Parameter>...</Parameter>
</Operation>

Reality in XMI is a bit more gossipy: (additions put in italics)

<Operation>
  <parameter>
    <Parameter>...</Parameter>
  </parameter>
  <parameter>
    <Parameter>...</Parameter>
  </parameter>
</Operation>

The definition of operations in MOF looks something like this:

The designer of UML knows, that ``parameter'' is the only way, to reach ``Parameter'' from ``Operation''. But the designer of MOF and XMI cannot rely on this. There could be another association beetween ``Operation'' and ``Parameter''. Therefore all <Parameter> elements must be enclosed by <parameter> elements, no matter how unneseccary it looks.