A Rule-based Conversion of an Object-Oriented Database Schema to aSchema in XML Schema

Fabiana Frata Furlan Peres Ronaldo dos Santos Mello Western Paraná State University Federal University of Santa Catarina Engineering and Exact Sciences Centre Informatics and Statistics Department Foz do Iguaçu, PR, Brazil Florianópolis, SC, Brazil ffrata@unioeste.br ronaldo@inf.ufsc.br

Abstract

Data interchange between different computersystems is a common task today, and the use of XMLas an exchanging protocol has increasing. XMLSchema recommendation allows the definition of anXML structure to be used for applications thatcommunicate data each other. This paper proposesa rule-based approach for converting object-oriented (OO) database schemata to XML Schemaschemata, as well as an algorithm that defines theapplication of the rules. We consider a schemamapping process in the OO� XML direction basedon a detailed analysis of the OO database modelconcepts. A prototype tool was implemented tovalidate the process. Compared to related work, ourproposal considers the mapping of all OODB modelconcepts to equivalent data structures in XML.

1. Introduction

The search for solutions related to theinteroperability among heterogeneous computersystems has been growing in importance due to theincrease of systems’ functionalities and the high costfor its maintenance and adequation to newtechnologies. In this context, XML has been widelyused for several reasons, mainly because it is a self-descriptive format, supports a flexible representationof data, and it is an open and free pattern [1].

An XML-based approach for providing datainteroperability among information systems focuseson the definition of mappings among DatabaseManagement Systems (DBMSs) models throughXML structures. Several proposals have beenpresented for the XML to Relational Database(RDB) mapping due to the popularity of RDBs [2],[3], [4], [5] and [6]. However, little effort has beenconducted for the interoperability of OO DatabaseManagement Systems (OODBMS) using XMLprotocols, as shown in Section four. Despite a more

restricted use in terms of market, if compared withRDBs, OODBs are useful for the persistence ofcomplex data manipulated by OO applications.

In order to contribute with this problematic, thispaper presents a detailed approach for the conversionof an OODB schema to a schema in XML Schema,which is the most recent and robust W3Crecommendation for the definition of an XMLdocument structure. Different from related work, wedefine structures in XML for OODB data in a waythat is independent of data specification technologies,i.e., we focus on the general mapping of conceptsbetween the OO data model and the XML (XMLSchema) model. Additionally, we consider theconversion of all common OO data model concepts.

The proposed approach is based on a set ofmapping rules as well as an algorithm that establishesthe order of application of these rules for thegeneration of an XML schema that properlyrepresents an OODB schema.

This paper is organized as follows. Section twodetails our approach for OO � XML conversion andSection three validates it through a case study.Section four discusses related work and Section fiveis dedicated to the conclusion.

2. OODB to XML Schema Conversion

Our approach considers the set of basic conceptsfor the OODB data model, as suggested by theObject Database Management Group (ODMG) [7].Correspondences are established from the OODBmodel concepts to the concepts of XML Schemamodel through a set of mapping rules. Some fewrules are semi-automatic, being up to an expert userto decide for the best representation in XML Schema.The concepts of both data models are detailed in thefollowing.

This section also describes an algorithm thatregulates the application of the rules, as defined in[8].

2.1. Conversion Rules

A rule for mapping to the XML Schema model wasdefined for each concept of the OODB data model.Generally speaking, an OODB schema is composedby concrete (hold instances) and abstract classes.Each class has attributes and methods, as well asgeneralization/specialization relationships (we callthem inheritance relationships) with other classes[7]. This work does not deal with methods of a classbecause they represent parts of the applicationdomain logic that manipulate data.

A class attribute can be simple, complex orreference. A complex attribute has a structureddomain, defined through grouping types (multivalued– set or bag), tuple (a record) and list (multivaluedwith a predefined order for its values). Such astructured domain can be recursively defined, e.g., atuple attribute may have a field whose domain is alist. A reference attribute holds the identifier of anobject of a certain class as its domain, providing anassociation relationship between classes. A simpleattribute has an atomic data type, like integer orstring.

An inheritance relationship may be definedbetween two classes, where one of them (subclass)inherits attributes and methods of the other one(superclass). In this case, we said that the subclass isan specialization of the superclass. It is possible thata subclass inherits properties from more than onesuperclass (multiple inheritance). Given the OODBdata model, rules are defined in the following.

Rule C provides the conversion of concrete andabstract classes of an OODB schema, depending onhow they are defined. In XML, an equivalentstructure is established through the definition ofcomplex types with sub-elements or attributes thatcorrespond to the class attributes. These complextypes are defined by a sequence XML Schemaconstruct, which defines how the sub-elements mustappear in the nested structure of the type [9]. Otherrules detail the conversion of each attribute type.Rule C is defined as follows.

Definition 1 (Rule C -Class Conversion). A classwith name C generates:

A complex type named C with an indicator oforder sequence, if C is a concrete class

ORAn abstract complex type named C with anindicator of order sequence, otherwise.

Rules ST, RT, TT, LT and GT deal with theconversion of the attributes’ types in an OODB class.Rule ST generates a simple element or an attribute inXML Schema, depending on the desired design of theXML structuring. An XML attribute, for example,

reduces the size of an XML document, while anXML element provides more readability to thedocument. An expert user must decide for one ofthese alternatives. The mapping of atomic OODBdata types to XML Schema types is controlled by atable type conversion and it is not detailed in thispaper. Rule RT converts references between classesof an OODB schema for references between XMLelements using the ID and IDREF attributes of theXML Schema [9]. An ID attribute defines an uniqueidentifier to an XML element in an XML document.An IDREF attribute holds an ID value, establishing arelationship between two XML elements. Both rulesare defined in the following.

Definition 2 (Rule ST - Simple AttributeConversion). A simple attribute SA of type St

belonging to a class or to a complex structure E,generates:

An element of name SA with a typecompatible to St, sub-element of the elementor complex type that corresponds to E

ORAn attribute with a type compatible to St

and name AS belonging to the element orcomplex type that corresponds E.

A complex structure in Rule ST means a datadomain defined as a grouping of one or more simpleor complex attributes, like a tuple or a set of values.They are converted to a complex type, as defined bythe further rules.

Definition 3 (Rule RT - Reference AttributeConversion). A reference attribute with name RA,belonging to a class or to a complex structure E,that refers to a class named C generates:

An attribute with name RA and type IDREFbelonging to the element or complex typecorresponding to E

ANDAn attribute with name C-ID and type IDbelonging to the complex typecorresponding to C, if C does not have anID type attribute.

The three following rules consider that a complexattribute can be a direct class attribute or an attributedefined into a complex structure. For Rule TT, acomplex element T is generated to represent a tuple,being each tuple field converted by other rules to anested property (sub-element or attribute) of T.

Definition 4 (Rule TT - Tuple AttributeConversion). A tuple attribute T with componentattributes CA1, CA2, ..., CAn, belonging to a class orcomplex element E generates:

A complex element with name T with anindicator of order sequence, sub-element ofthe element or complex type correspondingto E

ANDNested structures of T, generated by theapplication of the conversion rules to CA1,CA2, ..., CAn, according to its type.

Definition 5 (Rule LT - List AttributeConversion). A list attribute L of type TL belongingto a class or to a complex structure E generates:

A simple element with name L whosedomain is a list with type TL, sub-elementof the element or complex typecorresponding to E, if TL domain is notstring nor a reference nor a complex classattribute

OR Generates:A complex element with name L with an

indicator of order sequence, sub-elementof the element or complex typecorresponding to E

AND An element named Item, sub-element of L,

with a structure generated by themapping rule for the TL type, with XMLSchema cardinality constraintsminOccurs and maxOccurs definedrespectively as “0” and “unbounded”

, otherwise.

A list attribute is a collection of primitive orcomplex data in an OODB. XML Schema offerssupport for the specification of lists of simple typeswith data type different from string. For other cases,a complex element is defined, holding the list and asub-element containing a structure that is defined bythe mapping rule for this kind of list, with minimalcardinality 0 and maximal cardinality N(unbounded).

Definition 6 (Rule GT - Grouping AttributeConversion). A set or bag attribute SB of type Tbelonging to class or to a complex structure Egenerates:

An attribute with name SB and typeIDREFS in the complex type correspondingto E;

ANDAn attribute with name C-ID and type IDbelonging to the referenced complex typecorresponding to a class C, if C does nothave an ID type attribute

, if T domain is a class C;OR

A complex element with name SB with anindicator of order sequence, sub-element ofthe element or complex type correspondingto E

ANDAn element named Item, sub-element of EC,with a structure generated by theconversion rule for the T type, with XMLSchema cardinality constraints minOccursand maxOccurs defined respectively as “0”and “unbounded”

, otherwise.

A set or bag attribute holds a group of values thatmay be simple or complex. It means that a complexelement must be defined in XML to maintain eachvalue occurrence. Depending on the value type, aspecific mapping rule must be invoked to convert itto a proper XML structure. The exception is a set ofbag of references, that generates only ID andIDREFS XML attributes.

Rule SI and Rule MI define the mapping ofinheritance relationships between classes in anOODB schema. In the first rule, the type derivationXML Schema resources (derivation by extension andderivation by restriction) are considered. Aderivation by extension means that an XML subtypeinherits the properties of a supertype and still definesadditional properties. It is useful to map OODBsubclasses with new attributes. A derivation byrestriction means that an XML subtype properties arethe same of the supertype, but the subtype can onlyredefine them. Rule SI foresees these two cases andadditionally a combination of them as a third possiblesituation.

Definition 7 (Rule SI - Simple InheritanceConversion). An inheritance relationship betweentwo classes with names C1 and C2, where C2 is asubclass of C1:

Generates a constraint of restriction typeover the complex type corresponding to C1in the complex type corresponding to C2, ifC2 only redefines inherited attribute fromC1

ORGenerates a constraint of extension typeover the complex type corresponding to C1in the complex type corresponding to C2, ifC2 only defines additional attributes,besides the ones inherited from C1

ORGenerate:

A complex type C1aux that makes aconstraint of restriction type over thecomplex type corresponding to C1

AND

A constraint of extension type, over thecomplex type corresponding to C1aux inthe complex type corresponding to C2

, if exists attributes redefinition as wellas definition of new attributes in theinheritance between C1 and C2

Our approach gives a special treatment to multipleinheritance relationships because the derivationfacility of the XML Schema recommendation doesnot allow multiple inheritance among complex types.In this case, we decide for repeating the definition ofthe XML supertypes in the definition of the subtypein order to maintain all of their properties in thesubtype. This action is provided by Rule MI.

Definition 8 (Rule MI - Multiple InheritanceConversion). An inheritance hierarchy where aclass named Cn inherits the properties of two ormore classes with names C1, C2,... ,Cm that ownrespectively, attribute sets {A1C1:T1C1, A2C1:T2C1, ...,AiC1:TiC1}, ..., {A1Cm:T1Cm, A2Cm:T2Cm, ..., AiCm:TiCm},where each pair Ax:Tx denotes, respectively, thename and the type of the attribute, generates:

The inclusion, in the complex type correspondingto Cn, of XML structures generated by the mappingof each domain Ti ∈ {T1C1, ..., TiCm} of an attribute Ai

∈ {A1C1, ..., AiCm}, if Ai is not redefined in Cn. In caseof conflicts, if two or more superclasses hold exactlythe same Ax:Tx definition, only one of them isincluded. Other kinds of conflicts are solved by theexpert user.

2.2. Conversion Process

The previous presented rules are invoked by aconversion process. Figure 1 presents the algorithmthat implements this process composed by threestages. The first one is responsible for the generationof the complex types in the XML Schema,corresponding to the OODB classes. The attributesand sub-elements defined for these complex typescorrespond to the classes’ attributes. Once definedthese high-level elements, the second stage maps theinheritance relationships, applying the correspondingrules to the found relationships.

The last stage defines a complex elementcorresponding to the whole OODB. This complexelement has a sub-element defined for each complextype generated in the previous stages, that correspondto a concrete OODB class The “unbounded”cardinality constraint allows XML instances havedifferent numbers of occurrences for each sub-element corresponding to a OODB class, being ableof representing any volume of data in the database.

3. Case Study

In order to validate our approach, a Java prototypetool was implemented with the support of the DOMAPI for generating the schema in XML Schema. Itreceives an ODL (Object Definition Language)1

document as input and generates a correspondingXML Schema document (XSD) as output. A casestudy was accomplished for part of an Universitydomain, as modeled at Western Paraná StateUniversity, Brazil. For sake of paper space, we focuson some information about students and colleges.

Figure 1. Conversion algorithm.

Figure 2 shows the (input) OODB logical schemadiagram instead of an ODL description because it ismore legible. Black arrows represent inheritancerelationships and white arrows denote associationrelationships. Solid boxes represent concrete classesand dashed boxes denote abstract classes.

Our University domain comprises one or morecolleges. A college offers a set of courses. Anundergraduate student may be enrolled in one ormore courses, and also alumni data is considered.

The conversion algorithm initially applies stage 1,creating the complex types that regard to the OODBclasses through the execution of Rule C. In this case,

1 ODL is the recommended data definition language forOODBMS.

/****** Stage 1 ******/For each class C in the OODB schemado: Applies Rule C;

For each attribute A of each classC do: Case A type be: primitive: Applies Rule ST; reference: Applies Rule RT; tuple: Applies Rule TT; list: Applies Rule LT; set/bag: Applies Rule GT;

/****** Stage 2 ******/For each C class that is a subclasson OODB schema do: If C owns multiple inheritance Then Applies Rule MI Else Applies Rule SI;

/****** Stage 3 ******/

1. Generate a complex element withan indicator of order sequenceand name OODB_schema;

2. For each defined concrete complextype that corresponds to an OODBclass in the XML schema do:

Generate a sub-element of thecomplex element OODB_schemawith cardinality constraintsminOccurs = “0” and maxOccurs= “unbounded”.

one abstract complex type called Student isdefined, being the other ones defined as concretecomplex types. Figure 3 presents the output XSDdocument2. Such definitions are shown on that.

STUDENT COLLEGE COURSE

NAME: string; NAME: string; NAME: string;ADDR TUPLE OF ( HOURS: float; CREDITS: STREET: string; COURSES: LIST integer; NUMBER: integer; OF course; COLLEGE: CITY: string; ) college; PHONES: LIST OFinteger;COLLEGE: college;

ALUMNI UNDERGRADUATE

GRAD_DATE: date ADMISSION_DATE: date; IN_COURSE: SET OF Course

ALUMNI- UNDERGRAD

Figure 2. Partial OODB schema for an university.

<?xml version="1.0"?><xs:schema><xs:complexType name="STUDENT"

abstract="true"> <xs:sequence><xs:element name="NAME"

type="xs:string"/><xs:element name="ADDR"><xs:complexType> <xs:sequence>

<xs:element name="STREET"type="xs:string"/> ... </xs:sequence>

</xs:complexType></xs:element><xs:element name="PHONES">

<xs:simpleType> <xs:list itemType=“xs:int”/>

</xs:simpleType> </xs:element> </xs:sequence> <xs:attribute name="COLLEGEtype="xs:IDREF"/> </xs:complexType>

<xs:complexType name="COLLEGE"> <xs:sequence>

<xs:element name="NAME"type="xs:string"/> ... </xs:sequence> <xs:attribute name="COLLEGE-ID"type="xs:ID"/> <xs:attribute name="COURSES"type="xs:IDREFS"/> </xs:complexType>

2 For sake of paper space, we present XSD document partially.

<xs:complexType name="COURSE"> <xs:sequence> ... </xs:sequence> <xs:attribute name="COURSE-ID"type="xs:ID"/> <xs:attribute name="COLLEGE"type="xs:IDREF"/> </xs:complexType>

<xs:complexType name="UNDERGRADUATE"base="STUDENT" derivedBy="extension"> <xs:sequence>

<xs:element name="ADMISSION_DATE"type="xs:date"/> </xs:sequence> <xs:attribute name="IN_COURSE"type="xs:IDREFS"/> </xs:complexType>

<xs:complexType name="ALUMNI"base="STUDENT" derivedBy="extension"> ... </xs:complexType>

<xs:complexType name="ALUMNI-UNDERGRAD"> <xs:sequence>

<xs:element name="NAME"type="xs:string"/>

... <xs:element name="ADMISSION_DATE"type="xs:date"/> </xs:sequence>

... <xs:attribute name="IN_COURSE"type="xs:IDREFS"/> </xs:complexType>

<xs:element name="OODB_SCHEMA"><xs:complexType><xs:sequence>

<xs:element name="COLLEGE"type="COLLEGE" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="COURSE" .../> <xs:element name="ALUMNI" .../><xs:element name="UNDERGRADUATE"

.../><xs:element name="ALUMNI-UNDERGRAD"

.../> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

Figure 3. Output XML schema for the case study.

For each mapped class, its attributes are in turninvestigated and specific rules are invoked,depending on its type. For the Student class, forexample, Rule ST is applied to the Name attribute,generating, by default, a sub-element Name of thecomplex type Student with an XML simple typeinteger. Rule TT is applied to the Addr attribute,generating an XML complex element Addr. Thisrule recursively invokes, in this case, Rule ST foreach one of the tuple attributes, generating three sub-elements of Addr named Street, Number andCity. Rule LT is applied to the Phone attribute. Aswe have a simple type different from string, an XMLlist type named Phone with domain integer iscreated. Rule RT is applied to the College attribute,since its domain is a reference to an object of College

class. In this case, an IDREF attribute calledCollege is generated for the complex typeStudent, and an ID attribute named COLLEGE-IDis defined to the complex type College, since thereis no other ID attribute for this complex type.

An example of set attribute conversion throughRule GT occurs in the Undergraduate class forthe attribute IN_COURSE. As we have a set ofreferences to Course objects in this attribute, anIDREFS attribute named Courses is defined in thecomplex type Undergraduate, as well as anCOURSE-ID attribute for the complex type Course.

In the stage 2, Rule SI is applied to theinheritance relationships involving Alumni andUndergraduate classes. In these cases, anextension type constraint is defined, given thatthe two subclasses only define additional attributes.Rule MI application generates the definition of allsub-elements of the complex types Alumni andUndergraduate in the complex type Alumni-Undergrad.

Finally, at the stage 3, the complex elementOODB_schema is created and the concrete complextypes become its sub-elements, as shown in Figure 3.

4. Related Work

Solutions have been proposed for theinteroperability of persistent objects through XML.Some of them work on the opposite direction of ourapproach, i. e., they deal with XML � OO mappings.Han et al. [10] defines an algorithm to store XMLdata in OODBs, taking into account the XMLdocuments schema. It requires that mapping rulesdescribing the desired structure of the DB bemanually inserted in the input XSD, which is itsmain drawback. Chung et al. [11] stores XML data inOODBs based on a schema described by an inputDTD (Document Type Definition), which is less richin terms of resources for schema specification thanXML Schema. Salim et al. [12] presents rules formapping an XSD to an OO schema aiming atgenerating a documentation that could make easydata maintenance. The resulting OO schema isdefined in the UML language [13], which is not aformat that allows straightforward schema generationin an OODB.

The work of Renner [14] defines an architecturebased on Java (JAXB) for communication amongJava and XML documents. A JAXB compiler isresponsible to generate Java classes from an XSD.XML data are instantiated to Java objects or vice-versa through predefined methods, which allows theusage of Java to manipulate an OODB. Despite ofdefining mappings in both directions, it only dealswith the mapping of Java programming languageconstructs. The same reasoning is followed by other

technologies that perform object persistence in XML,like XMLBeans [15] and Xstream [16]. Differentfrom them, we define structures in XML for OODBdata in a way that is independent of OOprogramming technologies for object definition andmanipulation, i.e., we focus on the general mappingof concepts between the OO data model and theXML (XML Schema) model.

On the other hand, some work provide mappingsat the conceptual level, specifically from UML toXSD [17] and [18]. The problem here is that theconversion process is much more complex becausewe can derive several logical schemata from a sameconceptual schema. One example is a many-to-manyrelationship between classes, that can be mapped to acomplex element or to a pair of ID/IDREFSattributes to represent the association in XSD.

A close proposal deals with XML-OO mappingsin both directions [19] and [20], but the conversionprocess is more complex because an intermediategraph structure of entities and relationships isconsidered for common representation of XML andobject schemata. User intervention to define thedesired element nesting level of the output XSD aswell as to specify inheritance relationships betweenentities are another drawbacks of the work.

For the best of our knowledge, our approach is theonly one that deals with the mapping of multipleinheritance relationships.

5. Conclusion

This paper presents an approach for mapping anOODB schema to an XML schema defined in XMLSchema. The application of the proposed schemaconversion process allows the presentation of OODBdata in XML format, given that XML is a realstandard for data exchange among computer systems.Our conversion algorithm is able to map the classesof an OODB schema, their attributes, as well as theirassociation and inheritance relationships, i.e., ourapproach considers the conversion of all commonconcepts of the OODB model to a compatible XMLstructure in XML Schema. This is our maincontribution, if compared to related work. Some ofthem, for example, ignore the conversion of complexstructures, like sets and lists, and none of themprovides a treatment for multiple inheritancerelationships.

Our proposal is also useful for datainteroperability between commercial OODBMS,considering that they usually give support to exportobject instances to XML, but not object schemata toXML [21], [22], and [23]. The exportation of XMLschemata will allow the further definition of XMLrepositories able to validate XML documents.

We have two immediate future work in mind. Thefirst one is to provide a completely automaticOO � XML conversion. Our process today have onlytwo rules that requires user intervention during itsexecution : Rule ST and Rule MI. For Rule ST, wecan previously set up one mapping alternative asdefault or automatically choose the best mappingbased on heuristics. For Rule MI, we must analyzeall the possible inheritance conflicts and defineautomatic mapping solutions, or at least defaultalternatives. The second one is the definition of amapping catalog for storing processed conversions. Itcan be useful for a schema reverse engineering, forexample.

We also intend to study possible optimizations ofthe resulting XML structure in order to obtain betteraccess performance. One example is to considernesting of some associated elements instead ofreferences through ID/IDREF resources. Finally,the prototype tool must be extended to support theconversion of OODB instances to XML dataaccording to the generated XSD.

References

[1] Extensible Markup Language (XML), Available at:http://www.w3.org/XML/.

[2] S. A.-Yahia, F. Du and J. Freire. “A ComprehensiveSolution to the XML-to-relational Mapping Problem”. In:VI CIKM International Workshop on Web Informationand Data Management (WIDM 2004), Washington, DC,USA, Nov 12-13, ACM, 2004. pp.31-38.

[3] C.R.M. Maurício and R.S. Mello. “Uma Abordagem deMapeamento de Esquemas em XML Schema paraEsquemas Relacionais”. In: XXXIII Conferencia Latino-Americana de Informatica (CLEI 2007), San Jose, CostaRica, Oct 9-12, 2007 (in Portuguese).

[4] G. Kappel, E. Kapsammer and W. Retschitzegger.“Integrating XML and Relational Database Systems”.WWW Journal, v.7, n.2, Dez, 2004. pp. 343-384.

[5] P. Martins and A.H.F. Laender. “Mapeamento deDefinições XML Schema para SQL1999”. In: XXSimposio Brasileiro de Banco de Dados (SBBD 2005),Uberlandia, Brazil, Oct 3-7. pp. 100-114 (In Portuguese).

[6] I. Varlamis and M. Vazirgiannis. “Bridging XMLSchema and Relational Databases. A System forGenerating and Manipulating Relational Databases usingValid XML Documents”. In: ACM Symposium onDocument Engineering (DocEng), Atlanta, USA, Nov 9-10, ACM, 2001. pp. 105-114.

[7] ODBMS.org, Available at:http://www.odbms.org/odmg.html.

[8] F.F.F. Peres, “Uma Proposta de Mapeamento doModelo de Banco de Dados Orientado a Objetos para o

Modelo XML Schema”, Master’s Thesis. UFSC: PPGCC,2005 (in Portuguese).

[9] XML Schema. Available at:http://www.w3.org/XML/schema.

[10] W. Han, K. Lee and B. S. Lee. “An XML StorageSystem for Object-Oriented/Object-Relational DBMSs”.Journal of Object Technology, v.2, n.1, 2003. pp. 113-126.

[11] T. Chung, S. Park, S. Han and H. Kim. “ExtractingObject-Oriented Database Schemas from XML DTDsUsing Inheritance”. In: II International Conference onElectronic Commerce and Web Technologies (EC-Web),Munich, Germany, Sep 4-6, 2001. pp. 49-59.

[12] F. D. Salim, R. Price, M. Indrawan and S.Krishnaswamy. “Graphical Representation of XMLSchema”. In: Advanced Web Technologies andApplications, VI Asia-Pacific Web Conference (APWeb),Hangzhou, China, Apr 14-17, 2004. pp.234–245.

[13] Object Management Group – UML. Available at:http://www.uml.org/.

[14] A. Renner. “XML Data and Object database: ThePerfect Couple?”. In: XVII International Conference onData Engineering (ICDE), Heidelberg, Germany, Apr 2-6,IEEE Computer Society, 2001. pp. 143–148.

[15] Xstream development team. Available at:http://xstream.codehaus.org/.

[16] T. A. X. Project. Apache XMLBeans. Available at:http://xmlbeans.apache.org/.

[17] N. Routledge, L. Bird and A. Goodchild. “UML andXML Schema”. In: XIII Australasian Database Conference(ADC), Melbourne, Victoria, Australia, Jan, 2002.

[18] T. Krumbein and T. Kudrass. “Rule-BasedGeneration of XML Schemas from UML Class Diagrams”.In: Berliner XML Tage, Berlin, Oct 13-15, 2003. pp. 213-227.

[19] T. Naser, R. Alhajj and M. J. Ridley. “ReengineeringXML into Object-Oriented Database”. In: InternationalConference on Information Reuse and Integration (IRI),Las Vegas, USA, Jul 13-15, IEEE Computer Society,2008. pp. 1–6.

[20] T. Naser, R. Alhajj and M. J. Ridley. “FlexibleApproach for Representing Object Oriented Databases inXML Format”. In: X International Conference onInformation Integration and Web-based ApplicationsServices (iiWAS), Linz, Austria, Nov 24-26, ACM, 2008.pp. 430–434.

[21] Versant. Available at: http://www.versant.com/.

[22] Matisse. Available at: http://www.matisse.com/.

[23] Orient Technologies. Available at:http://orientechnologies.com/.