An XML Schema Extension for Structural Information in Internet and Web-Based Systems

Transcription

1 An XML Schema Extension for Structural Information in Internet and Web-Based Systems Jacky C.K. Ma and Michael R. Lyu Department of Computer Science and Engineering The Chinese University of Hong Kong Shain, Hong Kong (852) {ckma1, ABSTRACT The Extensible Markup Language (XML) is widely used in exchanging and storing information for various Internetenabled applications. The semi-structure property of XML allows users to represent different data flexibly; however, it is not well fitted for many traditional data storage models. In this paper, we propose an extension on the XML Schema to include structural information of an XML document so that its receivers can understand the intended structure and handle it in the way the document author desires. In the extended Schema, we allow nontraditional indexing methods to be included to facilitate some applications that have special requirements. By combining various data models, an XML document can choose different indexing methods on different parts of the document. Standardizing such schema extension will benefit in indexing and retrieval as well as in data integration, and will change the habit of people using data structure by collaboration with infrastructures for data creation, modification and validation. This would greatly encourage productive software and data engineering for Internet and Web-based systems. Keywords Internet and Web-based Systems, Middleware Systems, Distributed Systems, Collaborative Systems, XML, Information Retrieval. 1. INTRODUCTION The Extensible Markup Language (XML)[14] enhances the development of information systems in data interchange and data storage. It provides a common format for expressing both data structures and contents with a simple text format. The open-standard of XML and its interoperability attract great attention in cross-platform development for a lot of Internet-based applications. XML by itself is only a markup language that would not be so powerful to revolutionize the information industry. The added value is indeed generated by the various kinds of supporting technologies such as XSLT to transform XML into a presentation output, or XPath to query the elements in XML. More importantly, there exist simple-to-use application programming interfaces (API) such as SAX and DOM to facilitate rapid development of XML-enabled applications. One characteristic shared by XML applications is that they are working with data heavily. XML eases the life of storing, validating and manipulating the data. Semistructured data allows flexible use of XML to represent various kinds of data, ranging from very structured tables as in relational databases, to relatively non-structured webpage markups like the markups in HTML. However, this semi-structured nature also raises several concerns in XML storage and retrieval. Extensibility and flexibility are considered as two of the core benefits brought by XML, allowing diverse and rapidchanging data structures to be represented. These benefits, however, may violate the design principles for persisting data [8]. Existing databases and data warehouses are built upon the assumption of static data schema, and not storing XML data optimally [10]. Besides the traditional relational data model, there are other approaches in storing and retrieving XML data. Object Databases and Content Management Systems are attempts to adopt XML in an object-oriented model and a documentbased model, respectively. Another approach is to build from bottom up to store and manage XML, which often takes a hybrid form of relational and object models, to address XML technologies such as DTDs, XML Schema, XPath, etc. We may call this approach as Native XML. Native XML may seem to be a promising approach to retrieve XML data efficiently, but its associated technologies are not yet comparable to those of relational database and object database in terms of stability, scalability, and reliability. Lots of research efforts are focused on this evolving area to improve XML usability [12]. Based on the Native XML approach, we will introduce an XML Schema extension to include additional structural information. The additional information specifies the processing model, and is used to determine the storage and processing method for a given XML segment, which in turn allows the processing system to optimize its performance. We can also define data structures other then the usual

2 tables and objects in the extended Schema in accordance with the implementation of the storage and query engine. Programmers can then choose from a variety of data models or even a hybrid form of them to store and manipulate their data without carrying the burden of implementation details. As an example, we include a Tree Model in our extended Schema to illustrate what can be done with this design. In this paper, we begin with an overview on current techniques in modeling XML, the subsequent issues, and our overall solution. Then we will describe a hybrid model of XML data, its representation in an extended XML Schema, and the corresponding query method. Afterwards, we present the design and implementation for a query engine that understands and processes XML data with our extended XML Schema. After describing some related work, we summarize our approach and provide an outlook on future work in the last section. 2. BACKGROUND XML is a metadata language, which means data about data. [11] XML data modeling is an activity of using basic XML elements to model data [4]. Meta-modeling is a process to find the most suitable and economical representation of real data on the abstraction level [9], which promotes reusability and thus saves development effort [7]. This attracts many researchers attentions recently as people realize that traditional storage solution is not adequate when applied to XML data. We describe common XML data modeling and the associate problems Common XML Data Modeling Tables Relational database management systems (RDBMSs) are central to most business applications. Having a long record of proven performance and plentiful supporting utilities, it is intuitive for people to store XML content in relational tables. This combination allows designers to develop robust Internet applications rapidly that are compatible with their legacy systems. This approach, however, often assumes that the underlying XML data carry certain degree of regularities as well as a static schema. Since one core advantage of XML is its flexible data structure, loosely structured XML data or XML data with rapid-changing schema is common. Consequently, they are not readily convertible to relational tables. They may result in a large number of sparse tables or they require a lot of efforts in keeping on modifying the tables to suit various data. Objects The object model provides a view that can fit into the design of XML. By mapping the elements and attributes of XML to objects, the Document Object Model (DOM) allows programmers to manipulate and navigate XML data in a tree-like model. The generic object structure of an object database provides a flexible manipulation for XML data in a natural way, but it also imposes heavy system loading and could not provide satisfactory performance in most commercial applications. Documents XML can be stored in a document-based approach, for which XML document is stored as an entity according to its metadata [8]. The entities are often referenced by filenames, and the processing system may treat the XML along with the referenced Schema and XSL files as a single unit to maintain their integrity. This seems natural for those systems that treat XML as HTML files in a web server. However, there is no clear definition for how people can access specific XML elements from the storage system and thus the storage mechanism cannot be facilitated as a full feature database. Native XML As XML becomes more and more an important technology, storage solutions specialized for treating XML and the associated technologies (Schema, XSL, XPath, etc.) as primary concerns are evolving. They target at providing maximum optimization for XML data and maintaining the flexibility at the same time, often by forming a hybrid of the above models. While this approach promises good support for XML contents as well as a great performance boost comparing to existing XML storage schemes, this is an emerging area which still requires more research work before it becomes mature and practical in the real world Problems In practice, some data are more naturally represented by tables, but some more by trees. Also some data are subjected to frequent schema changes, but some are tied to the legacy system in relational database. Consequently, it is not a good idea to choose a single model for all kinds of data. Each single model will have its own constraints and insufficiency in dealing with certain type of data. The varieties of XML data models allow users to choose what is suitable for their application, but from another point of view, the users are still limited to one model once they have made the choice. This is particularly true when they have to purchase a relational database or an object database for their system. Another problem that raises people s concern is data integration [2], where there may be several data sources of different models. In our following proposed solution, we will provide a unified way for accessing data in various XML data models.

3 3. RESEARCH OBJECTIVES In our work, we aimed at building a system that optimizes XML content storage and provides a unified way for accessing different data models that facilitate data integration. Based on the native XML approach, we designed a hybrid model with an extension on the XML Schema. The extended XML Schema includes structural information, allowing users to specify the storage model for any XML data segments and to combine the models for composite data objects. The concept is extended to include additional models such as the R-Tree Model in this paper, which can provide alternative means for searching XML data. The R-Tree Model maintains a consistent mapping between the physical indexing and the XML document structure, thus allowing more efficient indexing and retrieval of XML data. Structural information is used in query engine to optimize the indexing and query processes. Some research work has been performed to mine the implicit structure information from documents [1,6]. Alternatively, our approach is to declare the structural metadata explicitly in the XML Schema as part of the XML document. Subsequently, it furnishes the necessary information to an XML query engine to optimize indexing and retrieval via the extended Schema. This approach allows the document authors to determine how the data should be indexed and stored. In particular, different parts of the document may be processed with different methods as declared in the Schema. It can also help to define how the data will be combined in data integration, and to supply a unified way for modifying and manipulating the XML data to maintain data consistency. Therefore, a higher-level data validation can be achieved, comparing with DTDs or an ordinary XML Schema. Considering the heterogeneous usages of XML in Internet and Web-based systems, the extended Schema is advantageous in assuring portable data structure declaration over the mining of implicit structure within the data server. This allows multiple data models to be integrated and transported through the Internet seamlessly. In short, the objectives of our work is: Describe the structural information of XML data. Adopt various operations in different data models. Combine data models to form hybrid model data objects. Query and manipulate the data in different models in a consistent format. Allow exchanging of structural information through the Internet. The approaches in achieving these objectives are described in the following sections. 4. XML DATA OBJECT MODELING In general, XML is consisted of tags in a hierarchical structure, which can be described by a tree model quite well. On the other hand, XLink [13] and other similar technologies provide referencing capability to XML, which allow XML data to be organized as a cyclic graph. Consequently, graph structure is used to give a generalized representation for the hybrid XML data models we mentioned. In the graph, we embody data objects as the nodes, and the directed edges are formed by the hierarchy of the XML itself or by the linking mechanisms like XLink. The foundation of a hybrid data model is the ordinary data models. The ordinary data models such as the tables and objects encapsulate the XML data and act as the building blocks, which may be called an Abstract Data Object (ADO). From the graph-structure of the XML data, ADO is capable of representing very different data structures, including relational tuples, free-form objects, and hierarchical tree structures. ADO has a number of properties, such as the unique identifier model name, statistical information like branching factors and branching criteria, instructive information like the boundary for current data object, and operational information like the constraints or logics in data manipulation. Most of the parameters are defined under specific data models, and the only generic parameter is the "model name" which is used to uniquely identify the data model. ADO is formed by a segment of XML, which is also a subtree of the complete XML document tree. As shown in Figure 1, ADO can be accessed from its Head Node only by its parent node or from outer referencing pointers (e.g. XLink). This helps in maintaining data consistency by keeping internal data from being accessed by external references directly. For outward pointers, it is possible to specify them in leaf nodes as well as in internal nodes. In the leave nodes, there may be data values or data objects, which may be unlabeled XML data, another ADO, or conventional data objects. In References Child Node Parent Node Head Node Abstract Data Object Leaf Nodes Child Node Out References Out References Child Node Figure.1 The Abstract Data Object

4 By joining the ADOs together using a tree structure or referencing links, we construct a composite data object, which may be viewed as a graph connecting various ADOs. Figure 2 shows an example of typical composite data objects. Object 1 R-Tree 1 Object 2 XML Root Object 3 Table 1 R-Tree 2 Figure 2. A Network of ADOs Object 4 As the ADO connections are a graph in nature, we cannot use the same set of operations as within the individual ADOs, such as relational operators or object operators. This limitation affects both the query and the manipulation languages that can be applied to this composite structure. 5. THE EXTENSIONS 5.1. Extended XML Schema After establishing an abstract, conceptual view on the hybrid data modeling, a concrete syntax is needed for creating and exchanging the metadata. As our target Internet applications are mostly based on XML and implemented upon the XML Schema, all XML-compliance requirements are applied to the following syntax and the syntactic flexibilities of XML are implicitly included as well. To begin, we add the namespace of mmx (i.e. an abbreviation for Multi Model XML ) in the <xs:schema> element: <xs:schema xmlns:xs=" </xs:schema> Listing 1. Schema for an ADO The schema element holds the definition of the target namespace, followed by the definition of document elements. For XML data not belonging to any ADO, the generic XML Schema and query methods still apply. ADO is the basic unit for our concern. When an XML element carries the function of ADO, it is defined by: <mmx:ado name="elementname" model="modelname"> <mmx:property> <mmx:propertyelt name="propertyname"> </mmx:property> <mmx:data>... </mmx:data> </mmx:ado> Listing 2. Schema for an ADO The ADO element carries an elementname, which is the tag name representing the ADO instance in the XML document. The modelname is the name of any defined data model. In order not to alter the structure in the XML document, the ADO parameters are put in the Schema directly. The <mmx:property> section wraps the <mmx:propertyelt>. The <mmx:propertyelt> element s attribute name is the name for the property, and the property value is the value of the element. The fields and data values of <mmx:propertyelt> vary for different data structures ADO, say, some properties of a relational table will not be applicable to a tree data structure. For the <mmx:data> section, it encapsulates the user data s schema. It uses the XML Schema to define how the XML data "appear" under the ADO, and how to follow the constraints set in the <mmx:property> section in order to validate the XML data according to the targeted data structure Query Language In order to figure out a cross-model query method, we first need a mechanism as a locator to address elements within the XML document. XPath, on its design purpose, is to support this need by using a compact, non-xml syntax, which facilitates its usage within Uniform Resource Identifiers (URIs) and XML attribute values. In our query language, XPath is used in pointing to the "Header Node" of an ADO or in returning an element address as the result. Within a query, we will need to specify the ADO to be called as well as the model-specific parameters. Following is a template for a typical query: <mmx:in <mmx:meta> xpath= XPath pointing to ADO method= MethodName callerid= CallerID /> <mmx:parameter> (Method specific parameters) </mmx:parameter> </mmx:in> Listing 3. Template for a Typical Query

5 The <mmx:in> element is the wrapper for the caller object. <mmx:meta> specifies the action to be invoked by giving the XPath of the ADO, and the action name. For <callerid>, it is optional and used to match the result object with the caller object when the query is remotely invoked. In the <mmx:parameter> element, parameters will be passed by using the XML syntax, which may be attribute value of an element, or a structured XML sub-tree encapsulated in a pair of tags. For the returned result, the format will be: <mmx:out <mmx:meta callerid= CallerID /> <mmx:result> (result set in XML) </mmx:result> </mmx:out> Listing 4. Typical Result Template The <mmx:out> element is the wrapper for the result object. The <mmx:meta> element exists only when the caller object specifies the calledid, and it just repeats the id specified by the caller. For <mmx:result>, it is similar to the nature of <mmx:parameter>, but this time it contains the returned result. 6. AN R-TREE EXAMPLE To demonstrate the concepts, we take R-Tree as an example. We show its Schema, the XML data instance, the query samples, and the result. R-tree [3,5] is a modification of B-tree for spatial data. It is balanced and splits the space into rectangles that can overlap with each other. Every node except the root node contains m to M children, where 2 m M/2. The root contains at least two children unless it is a leaf. The node is represented by the n-dimensional minimum boundingrectangle containing all the objects of its sub-trees. Each of the children of the node is split recursively. Listing 5 shows the example Schema of R-Tree ADO for M=3: <xs:schema xmlns:xs=" <mmx:ado name= rtree model= R-Tree > <mmx:property> <mmx:propertyelt name= key > <key N= S= E= W= /> <mmx:propertyelt name= internal > <node id= /> <mmx:propertyelt name= data > <data x= y= /> <mmx:propertyelt name= max > 3 </mmx:property> <mmx:data> <xs:sequence> <xs:complextype name= key > name= E type= xs:digit > name= W type= xs:digit > name= N type= xs:digit > name= S type= xs:digit > </xs:complextype> <xs:choice> <xs:complextype name= node minoccur= 1 maxoccur= 3 > <xs:element ref= rtree /> name= id type= xs:digit > </xs:complextype> <xs:complextype name= data minoccur= 1 maxoccur= 3 > <xs:any/> name= x type= xs:digit > name= y type= xs:digit > </xs:complextype> </xs:choice> </xs:sequence> </mmx:data> </mmx:ado> </xs:schema> Listing 5. Schema for R-Tree ADO Listing 6 shows the corresponding instance of the XML data. The creation of the XML data and the validation of the data against the data model s requirement, however, are not shown in this paper. We assume the data are valid in the query that is described later. <rtree> <key N="7" S="3" E="16" W="1"/> <node id="1"> <key N="7" S="3" E="6" W="1"/> <node id="1"> <key N="7" S="5" E="2" W="1"/> <data x="1" y="5">itema</data> <data x="2" y="7">itemb</data> <node id="2"> <key N="4" S="3" E="6" W="4"/> <data x="4" y="3">itema</data> <data x="6" y="4">itemc</data> <node id="2"> <key N="6" S="4" E="16" W="8"/> <node id="1"> <key N="6" S="5" E="16" W="9"/> <data x="9" y="5">itemd</data> <data x="16" y="6">iteme</data> <node id="2"> <key N="5" S="4" E="8" W="11"/> <data x="11" y="5">itemf</data> <data x="8" y="4">itemg</data> </rtree> Listing 6. XML Instance of R-Tree

6 For example, when we make a query like this: <mmx:in <mmx:meta> xpath= XPath pointing to <rtree> method= querynearest callerid= 001 /> <mmx:parameter> <x>2</x> <y>8</y> </mmx:parameter> </mmx:in> Listing 7. A Sample Query for R-Tree There is no data point at (x,y)=(2,8), but the nearest search in R-tree returns the point that is nearest to the given point, i.e., (x,y)=(2,7), which is itamb. Therefore, the result looks like: <mmx:out <mmx:meta callerid= 001 /> <mmx:result> <data x="2" y="7">itemb</data> </mmx:result> </mmx:out> Listing 8. A Sample Result of a Nearest Query for R-Tree As ADO is merely a representation for the data, to process the schema and queries we need an ADO engine. The ADO engine bridges the XML representation and the physical representation of data in the storage. It implements the XML Schema, parses the XML segment of the corresponding ADO and extract the data values, and indexes the data according to the data structure in a native manner. With a modular design, it is easy to add new ADO supports for different data structures. For the R-Tree example, we build an R-Tree ADO engine, which reads the Schema within the tags <mmx:ado name="rtree" model="r-tree"> </mmx:ado>. It obtains the necessary parameters from the <mmx:property> section, and validate the XML data with respect to the <mmx:data> section. On parsing the XML file, when the tag <rtree> is encountered, its sub-tree will be passed to the R-Tree ADO engine. As a result, the R-Tree ADO engine extracts the data values according to the Schema, and indexes the values using the native R-Tree approach. Under a query, when the XML parser finds that the query is made to a node of <rtree>, it will, again, pass the process to the R-Tree ADO engine. The R-Tree ADO engine will perform the query in the native R-Tree data structure, gather the answer, and generate an XML output as the response. 7. DISCUSSION One major purpose of our work is to provide structure metadata about the XML data. We note the trend from pure text message to HTML, where tags are added to markup the message for presentation. Then we move from HTML to XML, where the presentational tags are released for general purposes. Finally the XML Schema, in some sense, is to markup the XML data for processing. Our extended XML Schema is exactly following this trend. Traditionally, people have to choose one type of storage model for their XML documents, even though each type of modeling has its own pitfalls. With the structural metadata provided by the extended XML Schema and a front-end engine, performance in querying within any ADO should be comparable to that of the original storage method, since the modeling method is not changed. In addition to the traditional models, we may include other models to handle the data. In our example, we have an R- Tree structured XML document, which is presented as an R-tree and indexed as an R-tree. This kind of modeling provides a proper solution to many problem-specific Web applications, allowing heterogeneous data structures to be portable and interoperable across the Internet. Moreover, there is a significant difference between storing XML as some data structures and putting a data structure in XML. In the former case, very few assumptions can be made to the XML documents, and conversations have to be done to change the structure of XML into some other forms. In the latter case, however, we know most properties of the data structure. By representing the data structure using the XML, we can visualize and modify the data properly, and later carry out searching based on the nature of the defined data structure. This would be much more efficient and sensible in most cases. In fact, the Schema is not only used in searching and indexing XML files, but also provides a framework for people to interchange the information on their data structures. By collaborating on a standard implementation, just like the XML specification, different software systems can process an XML document in the same way as expected by the original author. This will facilitate distributed components to share a document properly. The improvement in this interoperability of XML will also improve the quality in data integration. Moreover, data creation and manipulation, and data validation are two types of infrastructures that work with indexing/retrieval in collaborative systems. Combining both of them will give us a framework that could shape how people manage their data: when an R-Tree is not easily applied, it is possible that people would just use the relational database to store the information, which may be a worse solution. Currently, when people need some advance data structures, they have to write non-disclosed code and store the data in proprietary formats, which is poor in reusability. With the extended Schema, once there exists a module to process a particular data structure, it can be reused and distributed easily, and thus change the habit of how people use structural data.

7 8. CONCLUSION In this paper, we review the common storage model for XML data including tables, objects, documents and native XML. However, most useful information is assumed in its native data model. Treating various kinds of information as the same XML data and forcefully storing them in any particular data model will not yield any benefit. Consequently, we propose a new approach of handling traditional data structures by expressing them in XML. With this approach, the fundamental unit of data can be any kind of legacy data structures with well-known storage and retrieval methods, and XML acts as a glue to these heterogeneous data structures. We model the generic data structure as Abstract Data Object (ADO), and make the corresponding declarations in an extended XML Schema. We define the extended schema, corresponding query operations, and the response messages in XML formats. An example is given on an R- Tree ADO to demonstrate how data are represented and operated. Our approach can be generally applied to other data structures such as relational tables, object modeling, B-Tree, Quad-Tree, AVL-Tree, S-Tree, etc. Note that there are many more data structures that are not listed here, but the approach would be similar. Moreover, XML not only binds different data structures together, but also provides a common representation that is easy to visualize, edit, exchange, and process. ADO engines offer a generic process for reusable data structures and thus shorten the time for software development. In summary, our approach presents a viable solution for "interoperable data structure" which facilitates data integration concerning software reusability. REFERENCES 1. B. Adelberg. NoDoSE: A Tool for Semi-Automatically Extracting Structured and Semistructured Data from Text Documents. Proc. ACM Sigmod Int l Conf. Management Data, ACM Press, New York, 1998, pp Elisa Bertino, Elena Ferrari. XML and Data Integration. IEEE Internet Computing, Vol.5, No.6, pp.75-76, A. Guttman, "R-Trees: A Dynamic Index Structure for Spatial Searching", Proc. ACM SIGMOD Conference, Boston, 1984, pp Zaijun Hu, Gerhard Vollmar: Towards XML Metamodel Patterns for XML Data Modeling. 12 th International Workshop on Database and Expert Systems Applications (DEXA 2001), 3-7 September 2001, Munich, Germany. IEEE Computer Society 2001, pp Petr Kuba, "Data Structures for Spatial Data Mining," RS pdf 6. D. Mattox, L. Seligman, K.Smith. Rapper: A Wrapper Generator with Linguistic Knowledge. Proc. 2 nd Int l Workshop Web Information and Data Management, ACM Press, New York, 1999, pp Hafedh Mili, Francois Pachet, Ilham Benyahia, Fred Eddy. Metamodeling in OO. OOPSLA 95 Workshop on Metamodeling in OO, Workshop Summary, pp Ketan C. Patel. Storing XML Content. XML magazine. olumns/collaboration/kpatel/. 9. D. Riehle and T. Gross. Role model based framework design and integration. In Conference on Object- Oriented Programming Systems, Languages and Applications, Proceedings, pp , Vancouver, Canada, October Leonard J. Seligman and Arnon Rosenthal. XML s Impact on Databases and Data Sharing. IEEE Computer, Vol.34, No.6, pp.59-67, Dan Wahlin. Back to Basics: The XML Fundamentals. e_eprod/xml/. 12. The Lore Project XML Linking Language (XLink) Version 1.0. W3C XML Specification. W3C Consortium.