Balisage Paper: Utilizing new capabilities of XML languages to verify integrity constraints

Introduction

Unified Modeling Language (UML) has proved to be a powerful language for modeling software systems. Modeling is an important activity in the software development process. It is a good way of how to abstract from technical details of a software system and concentrate on structural, semantic and functional aspects of the system. In connection with UML, a methodology called Model-Driven Architecture (MDA) has been established. It proposes to start modeling a system at an abstract platform-independent level stripped from technical details and then specify the model with more technical details at a platform-specific level. From this level, actual executable code can be then generated (ideally) automatically. In practice, the step from the platform-specific model (PSM) to executable code requires usually some level of the designer's interaction, but nonetheless, the presence of the layered model is a significant improvement both during initial formation of the implementation and it's management in the future.

In our previous work (Nečaský 2012A, Nečaský 2012B), we have shown how beneficial it can be to interconnect the world of UML and MDA with the world of designing XML schemas. Our premise was the fact that complex software systems are often modeled with UML diagrams at the platform-independent level. In particular, a UML class diagram is suitable for modeling a conceptual schema of the application domain. Such schema is called schema in a platform-independent model or simply PIM schema in MDA terminology. The term model means a modeling language (the language of UML class diagrams in our case). Our method allows to exploit the existing PIM schema to design XML schemas in the system. Each XML schema is modeled as so called schema in a platform-specific model or simply PSM schema. A PSM schema is, again, a UML class diagram. It represents a part of the PIM schema and shapes it to the form of the aimed XML schema. From the PSM schema, the XML schema expressed in a selected language (we currently support XML Schema) can be derived automatically. We have implemented the method in our CASE tool eXolutio.

One advantage of such approach is that an XML schema designer takes an existing PIM schema and derives from it a PSM schema of the aimed XML schema. This is much easier then writing the XML schema manually even when the designer uses an XML schema visualization tool. Another advantage of using a PIM schema is that it prevents from inconsitencies between the XML schema and the conceptual schema.

Several UML/XML schema mapping approaches were proposed so far (Pagano 2009, Bauman 2009), the advantage of our approach is hidden in the fact that a software system usually does not presume only one XML schema, but a whole family of XML schemas each representing a selected part of the application domain (e.g. in the domain of of e-commerce, the system might contain following XML schemas: purchase order, product catalogue or customer detail). Moreover, several different XML schemas may overlap and share some part of the reality but may represent it differently (e.g., the concept of Customer in of e-commerce is shared by different XML schemas which represent it with different XML structures). Using our approach, the reality is modeled only once in the PIM schema and its different representations in different XML schemas are derived from the PIM schema as PSM schemas. When the designer examines a particular PSM schema, he can always track any used concept back to the common model and thanks to this fact never looses the "big picture". The management of a family of schemas is thus more efficient and error-proof. Moreover, our approach makes the XML schemas better readable - anyone can look up what real-world concepts modeled in the conceptual schema are represented with a selected part of a particular XML schema and, vice versa, how a selected real-world concept is represented in which XML schemas.

In this work, we extend our previous work towards modeling complex integrity constraints (ICs). ICs are a substantial part of every software system, equally important as a conceptual schema. However, most of them cannot be expressed with UML class diagrams and, therefore, Object Constraint Language (OCL, see OCL specification) was introduced for this purpose. OCL is a formal language which can be used to declare ICs over a UML model. The ICs are in a form of logical expressions and can check constraints such as "employee, who is a division manager, must have a collage degree" or "the store manager can get a bonus only when the profits have grow at least 10% compared to last year" (the following section contains more examples of integrity constraints and how they are expressed fromally in OCL) . Usaing OCL has two main benefits in comparison to the natural language:

The authors of Dresden OCL toolkit (see Dresden OCL) have demonstrated how OCL ICs can be checked at runtime in Java (by translating OCL into Java code and adding triggers that verify the constraints when objects are changed) and also in relational databases (by translation of OCL expression into SQL statements, which allow to select records violating the IC).

When a system uses XML (e.g. for message exchange in communication or storing data), the ICs should be checked in the XML data and using XML technologies. In this work, we show how OCL ICs can be checked at runtime in XML documents using Schematron. The result of our research can be again profitably used by XML schema designers in cases when a PIM schema complemented with OCL ICs. Together with modeling the XML schemas as PSM schemas derived from the PIM schema, the designers can also easily convert OCL ICs from the PIM schema to the PSM schemas.

Having OCL ICs expressed at the platform-independent level the question is how they can be translated to the platform-specific level and from here to the XML schema level. The conversion to the platform-specific level is not covered in this paper. Just let us note that we have already implemented several methods for this conversion in our tool eXolutio but we do not describe them in this paper. Instead, we focus on the actual conversion of OCL ICs expressed at the platform-specific level to their suitable XML conterpart, which are Schematron schemas. Figure 1 shows an overall architecture of the system.

Figure 1: eXolutio - architecture overview

Schematron is a rule-based XML schema language based on XPath expressions. It is often used as a complement of grammar based schema languages (such as XML Schema, Relax NG or DTD), which define a proper vocabulary and validate the structure of the XML document, to check data and co-occurrence constraints - it serves a similar purpose, as does OCL in UML. Because the approach used in OCL to build expressions is rather different than the space of expression provided by XPath, it is necessary to extend XPath to provide comparable expressive power. We implemented the required extensions in our XSLT functions library called OclX. Since Schematron validation is usually implemented as several steps of XSLT processing, our extension will not require modification of the existing Schematron validation tools, except referencing OclX library. We will examine different approaches, how the required functions can be implemented, and show how several of the new constructs (such as higher-order functions, maps, or error-recovery instructions) proposed in the 3.0 drafts of XPath, XQuery and XSLT can serve our goal.

OCL Constraints

In this section, we will show on several examples the usage of OCL constraints.

Figure 2 shows a sample platform-independent schema of a chess leagues information system. ^[1].

Figure 2: A sample platform-indpendent schema

Figure 3 shows some constraints defined for the PIM schema. We will not elaborate the syntax of OCL in detail in this paper. Briefly: OCL script consists of declaration of blocks of integrity constraints, each block starts with the selection of context class and contains one or more invariants for this class. The invariants are logical expression refereing to the concepts defined in the PIM schema. Standard OCL does not allow to specify an error message describing the violated constraint. However, this is a valued feature of Schematron which we did not want to lose. That is why we extended OCL to allow an optional message after each invariant definition. The message can contain subexpression, as is shown in IC PIM1.

context Tournament
/* PIM1 */
inv: start <= end
message: 'Dates inconsistent {start} is grater than {end} in {name}'
/* which is an abbreviation for: */ 
inv: self.start <= self.end
/* PIM2 */
inv: matches->forAll(m:Match | m.start >= start and m.end <= end)
message: 'All matches in a tournament occur within the tournament’s time frame'
/* PIM2 in the previus is in fact an abbreviation for: */
inv: self.matches->forAll(m:Match | m.start >= self.start and m.end <= self.end)
/* PIM3 */
inv: matches->forAll(m | m.players->forAll(mp | mp.tournaments->includes(self)))
message: 'A match can only involve players who are accepted in the tournament'
/* PIM4 */
inv: matches->exists(m:Match | m.start.equals(start))
message: 'Each tournament conducts at least one match on the first day'

From this schema, two platform-specific schemas (Figure 4, Figure 5) were created, each using the classes from Figure 2, but each for a different type of XML documents used in the system. XSDs obtained from the PSM schemas are shown alongside the figures.

Figure 4: A sample platform-specific schema modeling a type of XML documents for Matches and Players involved in a Tournament

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="tournament" type="Tournament" /> <xs:complexType name="Tournament"> <xs:sequence> <xs:element name="name" type="xs:string" /> <xs:element name="start" type="xs:dateTime" /> <xs:element name="end" type="xs:dateTime" /> <xs:element name="matches" type="Matches" /> <xs:element name="participatingPlayers" type="Players" /> </xs:sequence> </xs:complexType> <xs:complexType name="Matches"> <xs:sequence> <xs:element name="day" type="Day" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="Players"> <xs:sequence> <xs:element name="player" type="Player" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="Player"> <xs:sequence> <xs:element name="name" type="xs:string" /> <xs:element name="email" type="xs:string" /> </xs:sequence> </xs:complexType> ... </xs:schema>

Figure 5: A sample platform-specific schema modeling a type of XML documents for Tournament Qualification

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="tournaments" type="Tournaments" /> <xs:complexType name="Tournaments"> <xs:sequence> <xs:element name="tournament" type="Tournament" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="Tournament"> <xs:sequence> <xs:element name="name" type="xs:string" /> ... <xs:element name="qualification" type="Qualification" /> </xs:sequence> </xs:complexType> <xs:complexType name="Qualification"> <xs:attributeGroup ref="OpenTournament-att-opt" /> <xs:attributeGroup ref="League-att-opt" /> </xs:complexType> <xs:attributeGroup name="OpenTournament-att-opt"> <xs:attribute name="open" type="xs:boolean" use="optional" /> </xs:attributeGroup> <xs:attributeGroup name="League-att-opt"> <xs:attribute name="leagueName" type="xs:string" use="optional" /> </xs:attributeGroup> </xs:schema>

Figure 6 shows, how the constraints from Figure 3 can be applied in the PSM schemas, where they are relevant. For the purposes of using OCL at the PSM layer, we added additional ways of navigation (to those defined in the standard) - parent and child_N, choice_N, set_N, seq_N (navigate to the n-th child, choice set or sequence in the content model of a class).

It is also possible to add additional constraints, which do not have a counterpart PIM constraint, for each PSM schema (e.g. constraint PSM5). In this paper, we will not show, how the relevant constraints are chosen for each PSM schema, but we will focus on how they can be verified in XML documents. (MARTIN: Tady ale zhruba rozved, jake jsou vyhody toho, ze to je na PIMu. Tj. odpovedi na otazku, proc si to nemuzu rovnou vyjadrit na PSM urovni?)

/*** Match schedule schema constraints ***/
context Tournament
/* PSM1 */
inv: start <= end
/* which is an abbreviation for: */ 
inv: self.start <= self.end
message: 'Dates inconsistent, {start} is greater than {end} in {name}'
/* PSM2 */
inv: matches.day.match->forAll(m:Match | m.start.after(start) and m.end.before(end))
/* abbreviation for: */
inv: self.matches.day->collect(d:Day | d.match)->
        forAll(m:Match | m.start.after(self.start) and m.end.before(self.end))
message: 'All matches in a tournament occur within the tournament\'s time frame'
context Match
/* PSM3: */
inv: matchPlayers.player->forAll(p | p.parent.parent.parent.parent.parent.
        participatingPlayers.player->exists(px | px.name = p.name))
message: 'A match can only involve players who are accepted in the tournament'
context Tournament
/* PSM4 */
inv: matches.day.match->exists(m:Match | m.start.trunc() = start.trunc())
message: 'Each tournament conducts at least one match on the first day of the tournament'
/*** Tournaments schedule schema constraints ***/
context Tournament
/* PSM5 */
inv: qualification.choice_1.child_1.open = true or
        qualification.choice_1.child_2.leagueName <> null
message: 'Tournament must be either open tournament or belong to a league'

From the nature of the excerpt Figure 6, it can be seen that contexts and invariants in OCL play the same role as rules' contexts and asserts in Schematron. The core of the transition from OCL to Schematron thus lies in translating OCL expressions into XPath tests, preserving the semantics. Some expressions (e.g. literals, if-then-else, variables, arithmetic, string and boolean operations, some collection operations) may be mapped directly to a corresponding XPath expression or function.

For some operations, a corresponding function does not exists or has a different semantics (e.g. OCL indexOf behaves just like XPath index-of when the searched item occurs at most once in the searched sequence, but XPath version returns indexes of all occurrences, when there are more). For these cases, we created a set of functions in OclX library preserving the semantics.

Feature-call expressions are a fundamental part of OCL - starting at a variable, they allow traversing the UML model along associations and accessing attributes. These are mapped to path expressions of XPath, which traverse the XML document. E.g. expressions self.start or self.matches.day can be expressed as $self/start and $self/matches/day respectively.

In the following sections, we will be dealing with those OCL constructs that cannot be expressed trivially - iterator expressions, tuples and nested sequences. We will also analyse the differences in error recovery in both languages.

Iterator expressions

In the examples above, a construct distinctive for OCL is used several times. It is the so-called iterator expression. An iterator expression is a certain kind of a function. It is always called on a collection object. It does not have ordinary parameters, instead each usage declares the iterator variable(s) it will use and a body expression. OCL standard library contains several predefined iterator expressions, the fundamental being iterate. Its most general form is:

 iterate(i; acc = {acc-init} | {body}) 

The semantics of the expression is as follows:

There are several facts regarding iterator expressions:

When we want to translate OCL ICs for XML, property 1 guarantees that showing how to express iterate and closure proves that other iterator expressions can be expressed as well, because they can be defined using these two (although the actual implementation would be often more efficient when implemented directly). Property 3 relieves us of the necessity of considering expressions with multiple iterators. Property 4 requires the translation to abide the rules for context and scope of variables. Every expression can refer to the global variable self and possibly other global variables declared explicitly by the user. Iterator expressions define local variables.

There is no construct similar to iterator expression in XPath, which is used by Schematron. In some special cases, iterate can be translated to XPath for expression, but not in general - whereas iterate can in each iteration refer to the result of the previous iterations (through acc variable), in XPath for, computations of every iteration are strictly separated. Thus, XPath must be extended to fully support iterator expressions and in this section, we will show several approaches, how it can be achieved. Since "iterate" is a name of a construct in OCL, a name of its implementation in our library OclX and also a name of an XSLT instruction, we will distinguish them by using iterate for the OCL construct, oclX:iterate for its implementation in OclX and by refering to the XSLT instruction as to xsl:iterate.

<xsl:value-of select="oclX:iterate(matches/day/match, false(), 1, 
      count(matches/day/match), current())" />
      
<xsl:function name="oclX:iterate">
  <xsl:param name="collection" as="item()*" />
  <xsl:param name="acc" as="xs:boolean" />	
  <xsl:param name="iteration" as="xs:integer" />
  <xsl:param name="total-iterations" as="xs:integer"/>
  <xsl:param name="self" as="item()" />

  <xsl:choose>
    <xsl:when test="$iteration &lt;= $total-iterations">
      <xsl:variable name="m" select="$collection[$iteration]" />
      <xsl:variable name="newAcc" as="xs:boolean">
        <xsl:sequence select="$acc or ($m/start eq $self/start)" />
      </xsl:variable>
      <xsl:value-of select="oclX:iterate($collection, $newAcc, 
                            $iteration + 1, $total-iterations, $self)" />
    </xsl:when>
    <xsl:otherwise>
      <xsl:value-of select="$accumulator" />
    </xsl:otherwise>
  </xsl:choose>
</xsl:function>

<xsl:function name="oclX:iterate" as="item()*">
  <xsl:param name="collection" as="item()*"/>
  <xsl:param name="iterationVar" as="xs:string"/>
  <xsl:param name="acc-init" as="xs:string"/>
  <xsl:param name="body" as="xs:string" />
  <xsl:param name="self" as="xs:item()"/>    

  <xsl:variable name="accumulatorInitialValue" as="item()*">
    <xsl:sequence select="dyn:evaluate($acc-init)"/>
  </xsl:variable>

  <xsl:sequence select="oclXin:iterate-rec($collection, $iterationVar, $accumulatorVar, 
     $accumulatorInitialValue, $body, 1, count($collection))"
  />
</xsl:function>

<xsl:function name="oclXin:iterate-rec" as="item()*">
  <xsl:param name="collection" as="item()*"/>
  <xsl:param name="iterationVar" as="xs:string"/>
  <xsl:param name="accumulatorVar" as="xs:string"/>
  <xsl:param name="acc" as="item()*"/>
  <xsl:param name="body" as="xs:string"/>
  <xsl:param name="iteration" as="xs:integer"/>
  <xsl:param name="totalIterations" as="xs:integer"/>
  <xsl:param name="self" as="xs:item()"/>     

  <xsl:choose>
    <xsl:when test="$iteration = $totalIterations + 1">
      <!-- return accumulated value -->
      <xsl:sequence select="$acc"/>
    </xsl:when>
    <xsl:otherwise>
      <-- iterator value for this iteration -->
      <xsl:variable name="m" as select="$collection[$iteration]" />
      <xsl:variable name="newAcc" as="item()*">
        <xsl:sequence select="dyn:evaluate($body)"/>
      </xsl:variable>
      <!-- call recursively -->
      <xsl:sequence
        select="oclXin:iterate-rec($collection, $iterationVar, $accumulatorVar, 
                  $newAcc, $body, $iteration + 1, $totalIterations, $self)" />
    </xsl:otherwise>
  </xsl:choose>
</xsl:function>

<xsl:evaluate xpath="$body">
  <xsl:with-param name="{accumulatorVar}" select="$acc" />
  <xsl:with-param name="{iterationVar}" select="$collection[$iteration]" />
  <xsl:with-param name="self" select="$self" />
</xsl:evaluate>

<xsl:function name="oclX:exists" as="xs:boolean">
  <xsl:param name="collection" as="item()*"/>
  <xsl:param name="iterationVar" as="xs:string"/>
  <xsl:param name="body" as="xs:string" />
  <xsl:param name="self" /> 
  
  <xsl:sequence select="oclX:iterate($collection, $iterationVar, 'acc', 
    'false()', concat('$acc or (', $body ,')'), $self)"  ></xsl:sequence>
</xsl:function>

<xsl:function name="oclX:iterate" as="item()*">        
  <xsl:param name="collection" as="item()*"/>
  <xsl:param name="accInit" as="item()*"/>
  <xsl:param name="body" as="function(item(), item()*) as item()*"/>
         
  <xsl:iterate select="1 to count($collection)">      
    <xsl:param name="acc" select="$accInit" as="item()*" />
    <xsl:next-iteration>
      <xsl:with-param name="acc" select="$body($collection[current()], $acc)" />
    </xsl:next-iteration>      
    <xsl:on-completion>
      <xsl:sequence select="$acc" />
    </xsl:on-completion>
  </xsl:iterate>    
</xsl:function>

<xsl:function name="oclX:exists" as="xs:boolean">    
  <xsl:param name="collection" as="item()*"/>
  <xsl:param name="body" as="function(item()) as xs:boolean"/>    
  
  <xsl:sequence select="oclX:iterate($collection, false(), 
      function($it, $acc) { $acc or ($body($it)) })" />   
</xsl:function>

<xsl:function name="oclX:existsN" as="xs:boolean">    
  <xsl:param name="collection" as="item()*"/>
  <xsl:param name="body" as="function(*)"/>
  <xsl:variable name="iteratorCount" select="function-arity($body)" as="xs:integer" />
  
  <xsl:iterate select="1 to xs:integer(math:pow(count($collection), $iteratorCount))">  
    <xsl:param name="satisfied" as="xs:boolean" select="true()" />  
    <xsl:variable name="indices" select="
      oclXin:getIndices(. - 1, count($collection), $iteratorCount, ())"/>
    <xsl:variable name="forThis" select="oclXin:functionItemCall(
      $body, $iteratorCount, $indices, $collection)" as="xs:boolean" />  
    <xsl:choose>
      <xsl:when test="$forThis eq true()">
        <xsl:break>
          <xsl:sequence select="true()"/>
        </xsl:break>
      </xsl:when>
      <xsl:otherwise>
        <xsl:next-iteration>
          <xsl:with-param name="satisfied" select="$satisfied or $forThis" />  
        </xsl:next-iteration>    
      </xsl:otherwise>  
    </xsl:choose>  
    <xsl:on-completion>
      <xsl:sequence select="$satisfied" />
    </xsl:on-completion>
  </xsl:iterate>
</xsl:function>  

<xsl:function name="oclXin:getIndices" as="xs:integer*">
  <xsl:param name="scalar" as="xs:integer" /> 
  <xsl:param name="base" as="xs:integer" />
  <xsl:param name="length" as="xs:integer" />
  <xsl:param name="result" as="xs:integer*" />
  <xsl:choose>      
    <xsl:when test="$scalar eq 0">
      <xsl:sequence select="
        (for $i in 1 to ($length - count($result)) return 0), $result" />
    </xsl:when>
    <xsl:otherwise>
      <xsl:variable name="mod" select="$scalar mod $base"/>
      <xsl:sequence select="            
        oclXin:getIndices(xs:integer($scalar div $base), $base, $length, 
                          (($mod), $result))" />
    </xsl:otherwise>
  </xsl:choose>
</xsl:function>

<xsl:function name="oclXin:functionItemCall">
  <xsl:param name="function" as="function(*)" />
  <xsl:param name="arity" as="xs:integer" />
  <xsl:param name="indices" as="xs:integer*" />
  <xsl:param name="a" as="item()*" />
  
  <xsl:sequence select="if ($arity eq 1) then $function($a[$indices[1] + 1])
    else if ($arity eq 2) then $function($a[$indices[1] + 1], $a[$indices[2] + 1])
    else if ($arity eq 3) then $function($a[$indices[1] + 1], $a[$indices[2] + 1], 
                                         $a[$indices[3] + 1])
    else error(QName('http://eXolutio.com/oclX/functional/error', 'oclXer:E001'), 
                     'A maximum of three different iterators are allowed. ')" />      
</xsl:function>

Tuples as maps

In this section we propose how to deal with tuples (anonymous types) from OCL.

OCL allows the designer to combine values in expressions into tuples. Tuples can be considered an anonymous type, which has a finite number of named parts. An example of a tuple may be Tuple { firstName = 'Jakub', lastName = 'Malý', age = 26 }. The values of the parts may be of arbitrary type, including collections and other tuples. The names of parts (firstName, lastName, age in the example) must be unique and are used to access the parts of the tuple in the expressions, similarly to attributes of classes, i.e. it is possible to write employees->collect( e | Tuple { name = e.name, salary = e.salary })->select( t | t.salary > 2000), the result of this expression would be a collection of tuples.

There is a noteworthy property coming with the possibility to create tuples: together with tuples, OCL was equipped with the operation product, defined as follows:

      product(c1:Collection(T1), c2:Collection(T2)) = 
        self->iterate(e1; acc = Set{} |
                c2->iterate (e2; acc2 = acc | acc2->including(
                      Tuple{first = e1, second = e2}) 
            ) 
        )

The result of product is a collection of type Collection(Tuple(first: T1, second: T2)), which contains all possible pairs where the first compound comes from collection c1 and the second collection c2. This operation thus finalizes the suite of equivalents of the constructs required for a language to be relationally complete (see Codd 1972):

Thus, not only tuples can be used to write more concise expressions, but, together with the operation product, they increase the expressive power of the language to relational completeness.

As far as XPath 2.0 is concerned, there exists no construct that could be naturally used to represent tuples, they can only be partially simulated. One possibility is to use sequences, where each item in the sequence corresponds to one part of the tuple, i.e. Tuple { firstName = 'Jakub', lastName = 'Malý', age = 26 } would be represented as a sequence ('Jakub', 'Malý', 26).

But this solution is not completely satisfactory from the following reasons:

Instead of representing tuples using sequences, an alternative would be to represent them using temporary documents, for example:

      <Tuple>
        <firstName>Jakub</firstName>
        <lastName>Malý</lastName>
        <age>26</age>
      </Tuple>

This approach would overcome the first issue (t.firstName would be represented as $t/firstName), the second issue (an empty element could represent a missing part) and also the third issue (nesting is no problem here and collections could be encoded into trees as well). However, it brings two problems of its own:

To conclude, restrictions inherent in XPath 2.0 data model prevent from satisfactory representation of tuples with semantics corresponding to OCL.

However, the possibility of extending the XPath/XQuery model with another item type - map - is being discussed and a prototype implementation is now available in Saxon (an alternative is to use XQuery implementation of maps using function items instead of map items, for details see Snelson 2011). The map type requires atomic values for keys and allow items of any type as values. These properties of map type make it a great candidate for representing tuples, thus, we decided to create a version of OclX which supports tuples represented as maps. Strings containing the name of a tuple part can be used as keys (and the names of parts must be distinct in an OCL tuple as well). The tuple from the example would be represented as map{'firstName' := 'Jakub', 'lastName' := 'Malý', 'age' := 26}, expression t.firstName would be represented as $t('firstName'). A value in a map can also be another map or sequence, which is consistent with semantics of OCL tuples. Operation product can be defined either by translating the definition from specification (using two nested iterates) or via a much more succinct expression:

   for $e1 in $collection1 return for $e2 in $collection2 
        return map{'first' := $e1, 'second' := $e2}

Different kinds of collections, nested collections

OCL defines an abstract type Collection and 4 different types of collections - Set, OrderedSet, Bag (in other languages sometimes called multiset) and Sequence. A member of any collection can be an arbitrary value, including another collection.

We treat all collections as sequences in OclX, yet it would be possible to represent the other kinds of collections using maps (or sequences as well).

Nested collections are a foreign concept to XPath data model. The disadvantages of encoding collections into temporary documents were discussed in section section “Tuples as maps”.

With the introduction of maps, there is a, rather ugly, way of encoding nested sequences - thanks to the possibility of using maps as values and members of sequences. A nested sequence ((1,2),(3),()) could be encoded to map{'s' := (map{'s' := (1,2)}, map{'s' := (3)}, map{'s' := ()})}, the expression returning number two would be written as (map{'s' := (map{'s' := (1,2)}, map{'s' := (3)}, map{'s' := ()})})('s')[1]('s')[2]. Using this approach also requires the functions which concatenate sequences not to use XPath operator ,, because it flattens the resulting sequence.

The double indexing (first to get the value from the map, second for getting the desired member of the sequence) can seem confusing, but it can be in fact hidden behind a library function at(i) (which OCL uses instead of the operator [i] to get an i-th member of a sequence). The wordy and a bit unclear way of creating a nested sequence appears in those expression that create nested sequences using literals. This, however, could be eliminated by using preprocessing of the schemas before evaluating the expressions (adding another step to Schematron pipeline).

Error recovery

OCL as a language has a direct approach to "run-time" errors or exceptions. Errors in computation cause the result of the expression to be invalid - a sole instance of type OclInvalid. It conforms to all other types and any further computation with invalid results in invalid - except for operation oclIsInvalid^[3], which returns true, when the computations results in invalid and false otherwise. This operation thus provides the only, very coarse-grained error checking (there are no error codes or exception types) available in OCL. Unlike OCL computation, XPath/XSLT 2.0 processor halts when it encounters a dynamic error and there is no equivalent of oclIsInvalid. It is also not possible to instruct it to jump to the validation of the next IC when a validation of an IC fails.

XSLT 3.0, however, introduces new instructions - xsl:try and xsl:catch - which provide means of recovery from dynamic errors. With these instructions, it is possible to implement oclIsInvalid as listed in Figure 13. We, again, utilize higher-order functions capabilities - the expression is evaluated in a function call wrapped in try/catch. OCL expression oclIsInvalid(1 / 0) can be translated to oclX:oclIsInvalid(function() { 1 / 0 }). Optionally, our validation pipeline (fully introduced in section “Implementation”) allows to safe-guard the evaluation of each expression using try/catch, so that the validation of another constraint may continue if a runtime error occurs and it is not contained by oclIsInvalid.

<xsl:function name="oclX:oclIsInvalid" as="xs:boolean">
  <xsl:param name="func" as="function() as item()*" />
  
  <!-- evaluate func and forget the result, return false --> 
  <xsl:try select="let $result := $func() return false()">
    <xsl:catch>
      <xsl:if test="$debug">
        <xsl:message select="'Runtime error making the result ''invalid''. '"/>
        <xsl:message select="'  - code: ' || $err:code"/>
        <xsl:message select="'  - description: ' || $err:description"/>
        <xsl:message select="'  - value: ' || $err:value"/>
      </xsl:if>
      <!-- if function call fails, return true -->
      <xsl:sequence select="true()" />
    </xsl:catch>
  </xsl:try>    
</xsl:function>

Implementation

We implemented the work presented in this paper into our XML schema modeling tool eXolutio, the workflow is depicted in Figure 14. The tool incorporates a UML and OCL editor for both PIM and PSM schemas and implements algorithm for suggesting/translation of relevant constraints from PIM to PSM (steps 1-3, not covered in this paper) and translation from OCL (4) to Schematron schemas. The user may choose between schema-aware and non-schema-aware (which add data conversion for extracting typed values from the XML document) schema and between implementation of iterator expressions using dynamic evaluation or higher-order functions. The generated schema can be then used to validate an XML document. XProc pipeline is then used to perform the validation. It first executes the transformation steps from standard Schematron pipeline (5.), adds includes for OclX library (6.) and then validates the document (7.) with the resulting XSLT. The pipeline expects the schema (5.) and validated document (8.) on its input ports and writes validation result - a SVRL document - to its output port (9).

Figure 14: Schematron and OclX pipeline

The tool itself (incl. examples), OclX library and the XProc pipeline are all available for free download on the tools website. Finally, Figure 15 depicts the translation of integrity constraints from the examples in Figure 6 (schema-aware, iterators via higher-order functions). The error messages defined in OCL translated into schematron error messages and their subexpressions into value-of instructions (see translation of PSM1).

<!-- Match schedule schema -->
<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">
 <sch:pattern>
  <sch:rule context="/tournament">
    <!-- PSM1 -->   
   <sch:assert test="start le end">
     Dates inconsistent, <sch:value-of select="$self/start" /> 
     is greater than <sch:value-of select="$self/end" /> 
     in <sch:value-of select="$self/name" />
   </sch:assert>
   <!-- PSM2 -->   
   <sch:assert test="oclX:forAll(oclX:collect($self/matches/day, function($d) { $d/match }), 
     function($m) { $m/start ge $self/start and $m/end le $self/end })">
     All matches in a tournament occur within the tournament's time frame
   </sch:assert> 
   <!-- PSM4 -->
   <sch:assert test="oclX:exists(
     oclX:collect(matches/day, function($d) { $d/match }), 
     function($m) { oclDate:trunc($m/start) eq oclDate:trunc($self/start) })">
     Each tournament conducts at least one match on the first day of the tournament
   </sch:assert>
  </sch:rule>
  <!-- PSM3 -->
  <sch:rule context="/tournament/matches/day/match">
   <sch:assert test="oclX:forAll($self/matchPlayers/player, 
     function($p) { oclX:exists($p/../../../../../participatingPlayers/player, 
       function($px) { $px/name eq $p/name }) })">
     A match can only involve players who are accepted in the tournament
   </sch:assert>
  </sch:rule>
 </sch:pattern>
</sch:schema>

<!-- Tournaments schedule schema -->
<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">
 <sch:pattern>
  <!-- PSM5: either open tournament or belongs to some league -->
  <sch:assert test="qualification/@open eq true() or exists(qualification/@leagueName)">
    Tournament must be either open tournament or belong to a league
  </sch:assert>
 </sch:pattern>
</sch:schema>

Expression rewriting and syntactic sugar

In many cases, iterator expressions and functions, can be expressed using a native XPath construct, e.g. forAll can be expressed as every/satisfies, select by application of a filter etc. The current version of the algorithm does not provide any of such rewritings, but in the following work, we plan to examine the possibilities of such rewritings and offer them to the user, where applicable.

OCL expressions have a useful property that they can be read from left to right thanks to the arrow notation '->' for collections and dot '.' for calling operations . When translated to XPath, the readability decreases (the object before the arrow/dot corresponds to the first parameter of the function. Also, the notation of higher-order functions in XPath is not so transparent. If desirable, it would be possible to preserve OCL notation even for Schematron schemas (and change it to usual XPath notation in another preprocessing step).

A valued feature of Schematron is the possibility to specify human-friendly error messages for violated integrity constraints. However, OCL does not provide such functionality in the current version of the standard (2.3.1). Since custom error messages were strongly advocated (e.g. in Malaika 2009), we extended recognized OCL grammar to allow specification of error messages.

Conclusion

In this paper, we inquired into the possibility of using OCL for modeling integrity constraints over XML data. We have discussed several ways of how non-trivial OCL expressions can be expressed using XPath with our proposed extension in a form of a XSLT function library OclX. The library itself contains a useful set of functions, which can be used on their own and provide a handy toolset with considerable expressive power. However, the main contribution is the possibility to check OCL integrity constraints in XML data. Our approach allows using the integrity constraints defined in the UML model also for XML, which supports consistency of the system as a whole (the constraints do not have to be rewritten by hand and managed manually after each change). It helps to bridge the gap between the platform-independent conceptual model and its applicability at runtime.

Since translated OclX constraints are, in structure, very simlar to OCL constraints, they will be easy to comprehend even for a modeller less familiar with XML technologies.

In the future, we want to thoroughly examine the possibilities of rewriting the expressions in order to use native XPath constructs to express iterator expressions where possible and allow the user to choose from several ways of expressing a certain constraint. As another part the future work, we plan to extend our approach for schema evolution and document adaptation (see Maly 2011) by utilizing OCL integrity constraints.

Acknowledgement

This work was supported by GAČR grant no. P202/10/0573.