8/4/2019 00945148

1/10

Ob ject-Oriented Represen tation for XML DataJingyu Hou, Yanchun Zhang

Department of Mathematics and ComputingThe University of Southern Queensland

{jingyu, yan}@usq.edu.auToowoomba, Qld 4350,Australia

AbstractXM L is a new standard fo r representing andexchanging data on the Internet. How to model XML datafo r Web appl ications and data management i s A hot topic

in XML research area. This paper presents an objectrepresentation model for XML data. A se t oftransformation rules and steps are established totrarisforni DTDs, as well as XM L documents wi th DTDs,into this model. This model capsulizes elements of X M Ldata and m anipulation methods. T his pure object-orientedmodel considers the features and usage of XML data andis suitable for Web applications as well a s XML datamanagenrent. DTD-Tree is defiried in this work torepresent DTD and describe the procedure to us etransfortiiatioti rules. DTD-Tree can also be used as alogical interface o r DTD processing.

1. IntroductionXML (e x te ns ib le Ma rkup La ngua ge ) [20] has beenrecommended by W 3C (W or ld W ide W e b C ons o r t ium) asa new standard document markup language forrepresenting and exch angin g data on the Internet.Compared with the main traditional markup language

HTML, which defines a fixed set of tags and dealsprimarily with the presentation aspects of documents onthe Internet, XML allows the definition of semanticallymeaningful tags. Ther efore, XM L assigns semantic andstructural meaning s to the data on the Internet. This makesit possible for Web applications and database managementsystems to manipulate, manage and retrieve the data onthe Internet. XML can also be used to define data transferformat, data manipulation algorithm or represent semi-structured data. Fo r example, in [ 3 ] , set of meaningfulXML tags a re defined in a DTD (Document TypeDefinition) file, then objects are represented as XMLdocuments used as interchange format. Due to its inherentflexibility, XML has attracted much research attentionrecently.

0-7695-1128-:i31 $10.00Q 2001 EEE 40

Yahiko KambayashiGraduate School of InformaticsKyoto University

Kyoto 606 8501,Japanya hiko@kuis.kyoto-U.ac. p

In general, XML data is an instance of semi-structureddata, which has no rigid schema. The structure, as well asthe contents , of the XML data evolves frequently.Therefore, the base for processing XML data ises tabl ishing sui table da ta model fo r XM L data . From thepoint of view of informat ion management , there is muchwork t ry ing to model XML data in to convent ional da tamodels, such as relational and object-relational models ,for example the work in [I] , [ I l l , [ IS] , [19] and [21].Howev er , f rom the point of v iew of da ta usage and W ebapplication development for XML data, object-orienteddata model is more sui table for XML data . The use ofobject model is driven by a number of factors [13],including:

The des ire to build software from reusablecomponents ;The desire for software to more directly andcompletely reflect enterprise concepts , rather thaninformation technology concepts;The need to support enterprise processes that involvelegacy information systems;The tendency fo r major software vendors toincorporate object concepts and facilities in keysoftware products .On the other hand, for information management, there

exist mature ob ject-oriented technologies.Many contributions have been made to the object-or iented model for XML data . For example, therepresentative work can be seen in [7] and [5]. In [7], theOEM (Objec t Exchange Model) [ 161 for semi-structureddata is extended to X M L data. XM L data in th is model isdescribed intuitively as a labeled, directed graph. Thenodes in the graph represent the data elements and theedges represent the element-subelement relationship.However , th is da ta model is a lightweight object modelan d it does not require the definition of classes or types, itdoes not support encapsulation and object behavior [ 131.W 3C 's Doc ume n t Ob je c t Mode l (DOM) [5 ] provides amechanism for scripts or programs to access andmanipulate parsed XM L content as a collection of objects .DOM represents a document as a hierarchy of objects ,

8/4/2019 00945148

2/10

called nodes, which are derived from an XML documentsource. Based on these objects , DOM defines an object-oriented API for processing the document. But there arestill l imitations for this m odel. For exam ple, it defines itsAPI at a general object level, not at application objectlevel, there is no application-specific object behaviordefined in this model and it is suitable for applications thatoperate on the document in memory as a whole [ I31 [15].There are also other attempts to model XM L document inapplication-specific object model, such as the work in[ IO ] . But model in this work does not define objectbehavior either and application of this model requiresusers have the knowledge of the object s tructure. Themanipulation of the object relies on the externalapplication program s or scripts.In this work, we will propose an object representationmodel (ORM) for XML data and provide a set oftransformation rules and steps for transforming X M L datainto O RM . XM L data re ferred to in this paper means DT Dfiles and XML documents with DTD, not including XMLdocuments without DTD. The work on XML documentswithout DTD is conducted separately. O ur model is pureobject-oriented and objects will capsulize features ofXML data, as well as methods for data manipulation andobject communication. Since Java is one of the mostpopular programming languages for developing Webapplications, we use Java objects to represent ourproposed objects for XM L data. Another im portant reasonfor choosing Java objects is that Java objects aresupported, as stated i n (31, by the new object-orienteddatabase management standard [4]. Therefore, o u r Javastyle ORM for XM L dat a considers the features and usageof XML data, and will be suitable for Web application anddata managem ent as well. These Java objects can be easilyconverted into other style objects in other object-orientedprogramming languages or data management sys tems .Meanwhile, we will define DTD-Tree to represent DTDand describe the procedure to use transformation rules.The DTD-Tree can also be used as a logical interface forDTD processing.

This paper is organised as follow. In section 2 , we willprovide some background for XML and propose theobject representation model for XML data. In section 3,transformation rules for transforming DT D into ORM willbe presented. DTD-Tree will be defined in section 4. It isused to represent the structure of DTD and describe theprocedure to use transformation rules for DTD. In section5, a set of transformation rules will be proposed forbuilding objects from XML documents withaccompanying DTD. In section 6, we will discuss somesimilar work. Finally, we will give some conclusions forthis work and discuss possible further work in section 7.2. XML & object representation model(ORM)

XM L Background XML is a semantic describinglanguage that allows users to define meaningful tags.Because the text is marked up semantically, it i s mucheasier for humans to read and computers to process. AnXML document is a file s tarting with a root element andcontaining nested elements. An XML document is knownas a well-formed if the elements nest properly w ithin eachother and create a tree-like structure (e.g. tags must bebalanced and matched, empty elem ent tags must eitherend with a /> or be explicitly closed). XML element canhave attributes attached to it and the attribute values mustbe in quotes. The following example shows a simple well-fo rme d XML doc ume nt :

8/4/2019 00945148

3/10

8/4/2019 00945148

4/10

.should be stored in a collection of attribute objectsfor a class (element).Values of elementsFor the same reason as above, values of elementsshould be capsulized in value objects and stored in acollection of value objects for a class.Subelements of elementsSubelements of an element (class) may be sequence,choice or mixed subelements, therefore objects forsubelements should also be capsulized in a collectionof subobjects for a class.Class methodsBehaviors should be assigned to the class to constructobjects, maintain and manipulate the status of objetsto reflect the changes to XML data, requirementsfrom applications or users. Therefore, the usage ofthe objects does not require users to have the innerstructure knowledge of the objects.All above aspects apply to all classes (objects), so asuper class, X M i D o c , with above features should be builtin the ORM for XML data . Figure 2 . l (a ) shows the

structure of this class. On the other hand, terminalelements, as well as attribute(s), only contain characterdata and have no subelements. This means the structure ofthem is certain. For this reason, another super class,Terminal , should be built for terminal elements as well asother information units in XML data with same features.Figure 2.1(b) shows its structure.Our OR M integrates the above two super classes, fromwhich classes and objects can be produced separately

from DDT files and XML documents. The elemcnt-subelement containment relationship is expressed in thisXMLD oc class

lass variables:oid: object identificationoname: object namecollection of attribute objectscollection of value objectscollection of subelements (sub-objects:lass methods:constructormethods for adding data into classmethods for deleting data from classmethods for updating data in classmethods for fetching data from classmethods for searching sub-objectsother required method s

model by the collection of subobjects of the class.Intuitively, the ORM is defined as a tree-like structure ofclasses (objects) in f igure 2.2.In figure 2.2 , an oval box represents a super class and arectangular box represents a class or objects . An arrowindicates the containment relationship. The super classObject is the unique super class in Java. One super classTerminal is not shown in this figure for the simplicityreason. It is implicitly referred to in the structure of theobject, as we will s tate next. Class methods are notindicated in the structure of the object in this figure. It canbe seen from this model that attributes and values of anelement, which are modeled as attribute objects and valueobjects of super class Terminal respectively, are stored inthe collection of attribute objects (CA) and collection ofvalue objects (CV) separately. The subelements of anelement, which are modeled as subobjects of super classXMLD oc , are stored in the collection of subobjects (CS).This ORM is in a uniform structure, which is easy tounderstand, covers all three kinds of information in XMLdata and is extensible. It meets the model design criteriastated previously.In order to represent DTD and XML document in thisORM, we still need some transformation rules. Thefollowing figure 2.3 logically describes this work.From abov e analysis and model, i t is known that thereare two kinds of transformation rules: one for DTD,another one for XM L docum ents. Transformation rules forDTD mainly deal with transforming DTD into classes i nthe ORM, while transformation rules for XML documentsdeal with transforming XML documents into objects inthe ORM.I Terminal class

____

:lass variables:oid: object identificationoname: object namecharData: character data

class methods:constructormethods for deleting data from classmethods for updating d ata in classmethods for fetching data from classother required method s

Figure 2.1. Structures of two super classes:XMLDoc and Terminal

43

8/4/2019 00945148

5/10

I. . 0 . . 0 . . 0 . . 0 0 . 0 . . 0 . .

D T D

Figure 2.2. Object representation model (ORM) for XML data

Classes & Mapping Appl ica t ionsR M & Ma pping+ Rules RulespqDocuments

Figure2.3. Work description3. Transformation rules from DTD to ORM objects in XMLDoc class can be implemented in Javausing the following format:

As indicated before, DT D describes a schema for a se tof XML documents . From a DTD, a col lec t ion of X M Ldocuments that conform to i t can be produced. Thefunction of DTD here is s imilar to that of class definitionin an object-oriented model (i .e from a class definition acollection of objects can be produced). Therefore, thetransformation rules fo r D T D is for transforming a D T Dinto a se t of classes in the ORM. Based on these classes,objec ts can be produced from concre te XML documents ,which will be discussed in the later section.

Since two super classes, XMLDoc an d Terminal, ar ethe base classes in the O RM , they should be establishedfirstly. That is the following rule.Rule 1. Two super c lasses , named X M L D o c an dTerminal, are created. Their s tructures are the same as

those defined in figure 2.1. XMLDoc is fo r nonterminalelements and other s imilar elements. Terminal is forterminal elements, elem ent attributes, element values andother s imilar elements.

For different object definition format, theimplementation of the Rule I is different. For ex amp le, thecollections of attribute objects , value objects and sub-

class XMLDoc{...Vector attributes = new Vector();Vector values = new Vector();Vector subobjects = new Vector();. . .

1

Rule 2. A new c lass is created for every element,inc luding a t t r ibute , in DT D. T he c lass name is the same asthe element or attribute name.This rule defines a principle that every information unitin DTD or XML documents is t rea ted as a c lass or anobject, not as an attribute of an object. For terminal,pseudo-terminal and nonterminal e leme nts, they will bemodeled as different classes. The following two rulesindicate these different cases.Rule 3. A class is created as a sub-class of Terminal fo revery terminal element or attribute in DTD. The classname is the same as the te rminal e lement nam e or attributename.

For example, for a DT D s ta tement

44

8/4/2019 00945148

6/10

the following class named publisher is created:class publisher extends Terminal{public publisher(String ObjectID,String ObjectName, String Cdata){super(ObjectID, ObjectName, Cdata);

11

Rule 4. A class is created as a sub-class of XMLDoc fo revery nonterminal or pseudo-terminal element in D T D .The class name is the same as the element nam e. This ruleis also applied to the element declared as AN Y orE M P T Y .The following rules define the containmentrelationships among the classes (element-subelementrelationship).Rule 5. The containment relationship between anelement E and its subelements is implemented by theconstructor method(s) of the class defined by that elementE. This rule guarantees the containment relationshipdefined i n DTD can be expressed in the ORM. In fact, amechanism can be built in the class constructor(s),according to the containment definition in DTD , to checkthe subelement type, order etc.. When an object of thisclass is to be produced, the subobjects of this object willbe checked strictly by the class constructor(s). If the checkis passed, this object will be produced. Otherwise, thisobject is rejected, which means the related XMLdocument does not conform to this DTD. For someextreme cases where the containment relationship isuncertain, for example the element declared as A N Y ,containment relationship can be implemented byprogramm ing and using the class methods.Rule 6 . For a nonterminal element E , its every (or a setof ) possible subelement(s) is mapped as an objectcollection of the class defined by that subelement. Thisobject collection is one parameter of the constructor ofclass E . I ) If the subelement is a terminal element, thecomponents of its object collection are put into the CV ofthe parent class E. 2 ) If the subelement is a nonterminalelement, the components of its object collection are putinto the CS of the parent class E.Rule 7. For an element E (pseudo-terminal ornonterminal element) that has attribute(s), its eachattribute is mapped as an object of the class defined by theattribute name. This object is one parameter of theconstructor of class E , and is put into the CA of the classE. Rule 8 . For a pseudo-terminal or nonterminal elementE that contains #PCDA TA type, this type is mapped as anobject collection of class Terminal. This object collection

is one parameter of the constructor of class E. T hecomponent of this object collection is put into the CV ofthe class E .For example, for the following element definitions:.. ....a class for nonterminal element LeaseContracts is createdaccording to the rules of 5, 6 an d 8:class Leasecontracts extends XMLDoc{public LeaseContracts(String objectID,String objectName, VectorterminalData, Vector Lesseevector,Vector LessorVector, VectorYearvector)

/ / termninalData is a Vector or/ / passing Terminal objects (#PCDATA)./ / Its components are put intoCV./ / Lesseevector is a Vector for/ / passing Lessee objects./ / Its components are put intoCs./ / Lessorvector is a Vector or/ / passing Lessor objects./ / Its components are put into CS./ / Yearvector is a Vector for passing//Year objects./ / Its components are put into CV.1.. .

1Rule 9. If a nonterminal element E has choicesubelements (indicated by the logical operator " I ' I ) , fo r

each choice, one constructor method is created for thisclass E . If the nonterminal element only has sequencesubelements, only one constructor method is created forthis class E.Remark: For subelements indicated by " * " or " ? ",different constructor methods can also be defined torespond to the possible appearances of the subelements.This work is easy but redundant. For simplicity, we willnot discuss this situation in detail.

45

8/4/2019 00945148

7/10

4. DTD-tree and transformation procedureW e de f ine a DTD-Tree to describe the logical and

structural relationship among the elements in a DTD ( inthis case, we temporarily do not consider object referenceor linking which will be for the further discussion). ADTD -Tree can be produced from appl ica t ion programs byparsing a DTD fi le . Jus t l ike document objec t mode(DOM) fo r XML doc ume n t 151, DTD-Tree can be anapplication program interface (API) for processing DTD,for example producing classes from a DTD by the aboveDTD transformat ion rules . This DTD-Tree can a lso beused to express the procedure to use transformation rulesfo r a DT D fi le .DTD-Tree is a directed and labeled tree. In the DTD-Tree, nodes represent elements in DTD, leaf nodesrepresent the data type (e.g. #PCDATA), directed edgesrepresent the containment relationship between an elem entand its subelements, a label on the edge indicates theoptional relation (*, +, ?, I). Attributes defined for anelement are indicated beside that node. The node with noname indicates a collection of subelements. A directededge without label indicates the subelement appears onetime in its super-element. For example, the bib.& can berepresented as a DTD -Tree in figure 4.1.This DTD-Tree expresses the element-subelementrelationship and optional relation in DTD. Although thereare many t ree schem as for descr ib ing X M L d ata current ly ,such as those in [7] [5] [17] and 191, our DTD-Tre edefinition is different from them. For example, treeschemas in [7 ] (OEM ) and [5] are for XM L documen t notfor DTD file, therefore the optional relations in DTD cannot be expressed. The tree schemas in [171 an d [9] are forDT D, but the schema s just express the simple element-subelement relationship, the optional relations as well asoptional collection of subelements in DTD can not beexpressed.

When the DTD transformation rules are applied to th eDTD (i.e. DTD-Tree), the procedure begins from the leafnodes, producing a set of classes by rules 2, 3, 4, 5, 7 and8. Then from the bottom to the top (root) of the tree, therules are applied level by level and finally all classes forthe DTD are produced. Let LN = {all leaf nodes oforiginal DTD-Tree 1, the transformation procedure isdescribed by the following algorithm.Step I . Crea te super classes XMLDoc an d Terminal by therule 1;Step 2 . Read DT D fi le and produce DTD-Tree ;Step 3 . For ( n E LN ) {If (n 's parent node nam e is different from names

of created classes) {If (n's na me i s #PC DATA) {

If ( n ' sparent node has only one child nodeand has no attributes) (a new class (sub-class of Terminal) iscreated for n' s parent node by rules 2 an d3;l i s parent node is marked as class;delete n from the DTD-T ree ;

IIf (n ' s parent node has only on e child nodeand has attributes) {a new class (sub-class of XMLDoc) iscreated for n' s parent node by rules 2, 4,5 , 7 , 8;iz 's parent node is marked as class;delete n from the DTD -Tree ;

1IIf ( n ' s na me is ANY or EMPT Y) {a new class (sub-class o f X M L D o c ) screated by rules 2, 4 for n' s parent nodewithout overriding the su per class

constructor;n's parent node is marked as class;delete n from the DTD-T ree ;

I1Else{

ii's parent node is marked as class;delete n from the DTD-T ree ;

IIIf ( n ' s name is different from nam es of created

Step 4. For (every node tz i n the DTD-Tree) {classes) {If (n'sall child nodes are marked as class ORthe names of n' s all unmarked child nodesare #PCDA TA or nul l) {

a new class (sub-class of XMLDoc) iscreated for n by rules 2, 4, 5 , 6 ,7 , 9;n is marked as c lass ;delete n's all child nodes from the DTD -Tree ;

}IElse{

IZ is marked as class;delete n' s all chi ld nodes from the DTD -Tree ;

I1

46

8/4/2019 00945148

8/10

Figure4.1. DTD-tree of bib.dtd"title",Data)5. Transformation rules for XM L document

with DTD to OR MThe rules for XML document with DTD describe howto produce instances (objects) of classes in ORM fromXM L documents. These classes have been produced byprocessing DTDs with the DTD transformation rules. Weconsider XML documents conforming to the same DTDas the same data source. In this w ork, we just d iscuss thesituation where every XML document in the data sourcehas a DTD which it strictly conforms to. For the situationwhere there is no DTDs, we will discuss it in the furtherresearch.Rule 1. For each matched pair of tags in XMLdocument, an object is produced. The object type (class) isthe same as the name of the tag. The name of the object isthe sam e as. he object type.For example, for the following XML documentsegment:

.. . Java Classes This subsection introduces Java

classes commonly used inprogramming.

...objects (objec t - t i t , objec t jam an d object-subsec) ar eproduced like this:Vector titleVec=new Vector();Vector paraVec=new Vector();String idNo="title-04"String cData="Java Classes"title object-tit=new title(iao,

...

titleVec.addElement(object-tit);idNo="para-03;cData="This subsection introduces. . ." ;para object_para=new para (idNo, para",

cData)paraVec.addElement(object9ara);idNo= subs c 0 ;subsection object-subsec=new subsection(idNo,"subsection",titleVec,paraVec);...

Rule 2. For each character s tring between a matchedpair of tags, if this tag is declared as a nonterminal orpesudo-terminal element i n DTD , an object of type (class)Terminal is produced for each string and put into a sameobject collection.Rule 3. If a pair of tags is declared as A NY in DTD,just an object of that class is produced. Other elementsbetween this pair of tags are processed by using the aboverules and the class methods defined in super classXMLDoc.In practice, to process an XML document by accessinginternal structure, we need to use application programinterfaces (APIs). Document Objec t Model (DOM ) [ 5 ] ssuch an API. In DOM, an XM L document is representedas a tree whose nodes are elements, text, and so on [15] .DOM provides a set of APIs to access and manipulatethese nodes in the DOM tree. DOM for an XMLdocument can be generated by many XML processors,such as XML fo r J a va [15]. Based on the DOM of anXML document, an application can be developed toproduce objects from the XML document by the abovetransformation rules for XML document. Just as thesituations in processing DTD, the application of thetransformation rules for XML document also starts withthe leaf nodes in DOM, produces objects level by levelfrom the bottom to the top of the DOM. Because of space

47

8/4/2019 00945148

9/10

limitation, we will not describe the algorithm in detail forthis procedu re.6. Similar work and discussions

Currently, representative similar work can be seen in[l], [7] and [lo]. [I] gives an object view of an XMLdocu me nt, but this view is not for DTD . Because thiswork mainly considers the transformation between XMLdocuments and relational databases, concrete andcomplete object model i s not proposed fo r XMLdocuments and DTD. The data model in [7] i s theextension of that for semi-structured data, O EM . This datamodel describes logical relationship of the elements inXML documents . There i s no concrete objectrepresentation mode l for the objects in this model. Toapply this data model , a proper object representationmodel should be established to meet the requirements ofapplication or systems.

[ I O ] , a set of translation rules is proposed fortranslating XML data, with or without DTDs, into classesor objects for a mediator. Terminal elements, as well asattributes of elements, in XML data are modeled asattributes (not sub-objects) of the object . However, theapplication of this model requires users have theknowledge of the object structure and the object variablesare manipulated directly. Furthermore, for the use of thismodel, special methods must be used to dist inguish whichobject attribute is for the terminal element and which isfor the attribute of an element in the original XMLdocument. For the changes of terminal elements orelement attributes, these special methods must be changedaccordingly. The extensibil i ty of this model is limited.For the element declared as AN Y in DTD, i t causes theproblem called incompleteness of DTD because i t cancontain any declared types. It is relatively difficult to dealwith this kind of element in a model for XML data. In[101, to deal with A N Y element, i t has to define new typesdynamically when read XM L documents or update objectvariables frequently from object attributes to sub-objects.It is complex and difficult in application development.Somet imes the order of the e lements in XMLdocuments is important for applications. But similarmodels for XML d ata in [ 101and [ 11 did not consider thiss i tuat ion. With our ORM, the above problems can besolved or techniques for process ing XML data can beimproved.

In

7. ConclusionsIn this work, we propose an object representation

model (ORM ) fo r XM L d a t a (DT D and XM L document swith DTD). A set of transformation rules and steps fort ransforming DTD and XML documents into this ORMare established. This ORM is pure object-oriented and

meets the model design cri teria of simplicity,completeness and extensibil i ty. I t capsulizes elements ofXML data and data manipulat ion methods in a uniformstructure. Therefore, manipulation for the objects of X M Ldocuments (such as information retrieval) can be easilyimplemented by developing corresponding object-orientedapplication programs and using the provided classmethods . This OR M is sui table for many web appl icat ionsand information retrieval.

Our O RM for XML data can be used for the s i tuat ionwhere the element order in an XM L docum ent needs to beconsidered, because the class variable oid in our modelcan be used to record the order. Retrieval by elementname and value can also be easily implemented in ourOR M, because the element name (wi thout change) andvalue are capsulized in an object . Different objects withthe same element (object) name can be identified by theobject identification oid.Due to the pure object-oriented characterist ics, thisORM is suitable for dealing with the problem ofincompleteness of DT D. Instead of dynamically definingnew types (classes) or updating obje ct variables when readXM L docum ents , our model i s in an uni form manner ofproducing an object for AN Y element and us ing the classmethods to deal with any elements contained within thatAN Y element pair.DTD -Tree def ined in this work can be used to describelogical structure of a DTD. It also can be used as an AP Ifor processing DTD, which is similar to D O M f o rprocessing XML documents. In this work, i t is used toexpress the procedure to use transformation rules.This work is under the assumption that all XMLdocuments conform s t r ic t ly to th e DTDs. However, inpractice many XM L documents are jus t wel l - formed wi thno DTDs. How to ext ract objects f rom these XMLdocuments i s also a challenge problem. Although there iswork on this topic (e .g. [ lo ] [ l ] ) , the work needs to beimproved further to fi t more complex situations, such asXML data containing reference or other enti t ies. Onenature way for solving this problem is considering toext ract DTD from X ML do cuments , but this work may bemore complex than the or iginal problem and may beanother research direction in this area. Another way is tobuild an object-oriented model that has abili ty to produceobjects dynamical ly when XM L docum ents are read. Thiswill be ou r further research work.

The object representat ion m odel for XM L data shouldbe able to deal with the exte ndin g capabili t ies of X M L ,such as addressing and l inking, internal and externalentities [2 ] [14]. Based on the proposed ORM, how toconstruct effective algorithms to retrieve the requiredinformation is also worth to be considered. Th ese will alsobe our further research directions.8. References

48

8/4/2019 00945148

10/10

[ l ] R. Bourret, C. Bornhovd. A. Buchmann, A GenericLoad/Extract Utility for Data Transfer Between XMLDocuments and Relational Databases, Proceedings of SecondInternational Workshop on Advance Issues of E-Cornmerce an dWeb-Based I t formation Systems (WECWISWO), Milpitas,California, USA, 8- 9 June, 2000.[2] A. Bergholz, Extending Your Markup: An XML Tutorial,IEEE Internet Computing, Vol. 4, No. 4, July/August 2000, pp74-79.[3] G. M. Bierman, Using XML as an Object InterchangeFormat, Technical Proposal, Department of Computer Science,University of Warwick, UK, 17 May, 2000.[4] R. G. G . Cattell et al , The Object Data Standard: ODMG 3.0,Morgan Kaufmann, 2000.[ 5 ] Document O bject Model (DO M) Level 1 SpecificationVersion 1 O. l i t t ~ ~ : / / ~ v ~ v ~ v . ~ v 3 . o r g f l ~ R E C - D O M - L e v e l - l ,998.[6] M.N. Garofalakis, A. Gionis, R. Rastogi, S . Seshadri, K.Shim, XTRACT: A System for Extracting Document TypeDescriptors from XML Documents, SIGMOD Record, Vol 29,Issue 2, June 2000, pp165-176.[7] R. Goldman, J. McHugh, J. Widom, From SemistructuredData to XML: Migrating the Lore Data Model and QueryLanguage, Proceedings of th e 2nd International Workshop 011the Web an d Databases (WebDB99) , Philadelphia,Pennsylvania, June 1999.[SI The Java Tutorial: A practical guide for programmers,October 2000, iitrl://java.siiii.coril/clocs/books/tiitoi.ial.[9] E. Kotsakis, K. Biihm, XML Schema Directory: A DataStructure fo r XML Data Processing, Proceedings the IInternational Corlference on Web Itlfortnation S!stemsEngineering (WISEOO),Vol. 1, Hong Kong, China, 19-21 June,2000, pp 56-63.[ lo ] H. Lin, T. Risch, T. Katchaounov, Object-OrientedMediator Queries to XML Data, Proceedings the IInternotional Conjerence on Web bl fonnat ion Sj~steinsEngineering (WISEOO), Vol. 2 , Hong Kong, China, 19-21 June,2000, pp 38-45.[ I I] A. H. F. Laender, B. Ribeiro-Neto, A. S . da Silva, and E. S .Silva, Representing Web Data as Complex Objects, ElectronicCommerce and Web Technologies, Proceedings o the FirstInternational Corference, EC -Web 2000, London, UK,September 2000, pp 216-228.[I21 J. McHugh, S . Abiteboul, R. Goldman, D. Quass, J. Widom,Lore: A Database Management System for Semistructured Data,SIGMOD Record, Vol. 26, No. 3 , September 1997, pp 54-66.[131F. Manola, Towards a Web Object Model, OBJS TechnicalReport, Object Services and Consulting, Inc. (OBJS), February1998, h ttp://w ww. bjs.condOSA/worn.httn 1.

[I41 S. McGrath, X M L by Example: Bui lding E-CommerceApplications, Prentice Hall PTR, U pper Saddle River, NJ, 1998.[I51 H. Maruyama, K. Tamura, N. Uramoto, X M L arid Java:Developing Web Applications, Addison-Wesley, Reading,Massachusetts. 1999.[16] Y. Papakonstantinou, H. Garcia-Molina, and J. Widom,Object Exchange Across Heterogenous Information Sources,Proceedings of the Eleventh Internatiorial Corlference on DataEngineering, Taipei, Taiwan, March 19 95, pp 251-260.[I71 W. Qian, L. Zhang, Y. Liang, H. Qian, W. Jin, A Two-Level Method for Clustering DTDs, Proceedings of th e FirstInternational Conference on Web-A ge Information Management(WAIMOO),Shanghai, China, 21-23 June, 2000, pp 41-52.[18] F. Sha, G. Gardarin, L. NCmirovski, Managing Semi-Structured Data in Object-Relational DBMS, Networking aridInfor~nation ysterns Journal, Vol. I , No . 1, 2000, pp 7-25.[I91 B. Surjanto, N. Ritter, H. Loeser, XML ContentManagement based on O bject-Relational Database Technology,Proceedings th e I International Coifererice on Weblnfonnatiori Sjs tems Engineering (WISEOO), Vol. 1, HongKong, China, 19-21 June, 2000, pp 64-73.[20] Extensible Markup Language (XML) 1 .O,http://www.w3.orgflWI 998/REC-~- tnl -998021 0[21] J. P. Yoon and V. Raghavan, Multi-Level SchemaExtraction for Heterogeneous Semi-Structured Data,Proceedings of the First lnternationcrl Conference on Weh-AgeIiEforniatiori Mariagernerit (WAIMOO), Shanghai, China, 21 -23June, 2000, pp 41 1-422.

49

http://www/http://www/