XML QUERY OBJECT MODEL: A GENERAL VIEW
F
´
abio Ribeiro Silvestre
Fundac¸
˜
ao Visconde de Cairu - CEPPEV
Rua do Salete 50, Barris - Salvador/BA - Brasil
Hernane Borges de Barros Pereira
Fundac¸
˜
ao Visconde de Cairu - CEPPEV and
Universidade Estadual de Feira de Santana - DEXA
Rua da Brisa 42, Ap. 1701 Pituba - Salvador/BA - Brasil
Keywords:
Querying Process, Semistructured Data, XQOM Schema, Framework Technology.
Abstract:
We have observed an increase in document search needs in organizations. This increase in document search
demand has required better efficiency on search software languages. The current technologies are using spe-
cific patterns to search documents. The most usual pattern, called XML, has been proposed by W3C and some
languages (e.g. XQL, XML-QL etc.) were created to recover XML documents. The implementation of a
XML query server, which abstracts the language used, has been an emerging necessity. This paper surveys
technology used to develop a XML query server, called XQOM Schema, from the modelling to the implemen-
tation. In an organization setting, we have adopted new abstraction forms of searching for XML documents
without the usage limitation established by a specific language. XQOM Schema may contribute to the creation
of an universal document searching pattern in XML format.
1 INTRODUCTION
Currently, the demand for documents search systems
has increased in organizations. The Internet’s growth
brings a some practical issues. For instance, how to
recover documents more efficiently? However, there
are some technologies to solve this problem that use
specific patterns to search documents, such as XML
(eXtensible Markup Language), proposed by W3C
(Consortium World Wide Web) (Bray et al., 1997).
Some XML query languages have been proposed to
W3C. Three of them are more usual: XQL (functional
pattern), XML-QL (relational pattern) and Lorel (ob-
ject oriented pattern). We propose a query server to
semi-structured documents based on XML language,
which abstracts the query language employed. We
have chosen the XQL and XML-QL languages to test
the proposed server. These languages use a driver de-
veloped by researchers at the Berkley University for
XQL and a driver developed by researchers at the
AT&T for XML-QL. (Robie et al., 1998; Research,
1999).
Despite the fact that investments (from the time and
money perspectives) in researches on query languages
are being carried out, there is a lack of products and
processes related to the information and management
knowledge, inside the organization. In general, or-
ganizations have a well-defined and almost inflexible
way for internal data structure. This, intuitively, im-
plies the use of conventional databases (e.g. relational
or object-oriented databases). However, the process-
ing of semi-structured data in these databases types
is inefficient since semi-structured data has a pre-
defined framework of data storing. On the other hand,
the semi-structured documents have a highly flexible
and irregular structure that makes the conventional
databases inappropriate, disabling the databases with
respect to the semi-structured data storing (Graves,
2001).
The main goal of this paper is to survey the XML
Query Object Model that consists of a server (frame-
work), called XQOM Schema, that allows the cre-
ation of several XML document search applications
used in an organizational context (e.g. to be worked
in an intranet). This server uses metadata to carry out
searches in electronic documents, aiming more pre-
cise results.
2 XML QUERY OBJECT MODEL
XML Query Object Model (XQOM) is a query server
to semi-structured data. Some function paradigms
must be observed by applications that aspire to use the
469
Ribeiro Silvestre F. and Borges de Barros Pereira H. (2006).
XML QUERY OBJECT MODEL: A GENERAL VIEW.
In Proceedings of WEBIST 2006 - Second International Conference on Web Information Systems and Technologies - Internet Technology / Web
Interface and Applications, pages 469-472
DOI: 10.5220/0001244904690472
Copyright
c
SciTePress
XQOM Schema. Two steps are essential. First step
determines that there will be an individual responsi-
ble for the creation of conceptual documents in a spe-
cific category. The second one implies that there will
be a mapping between conceptual model and stored
XML documents. These XML documents have been
created through XQOM Schema.
XQOM Schema is basically composed of two mod-
ules: administration module and query module. Thus,
there will be corresponding profiles: administrator
and end-user.
2.1 XQOM Architecture
In this section, we present the XQOM Schema func-
tional processes. Figure 1 depicts the XQOM archi-
tecture and its functionality is detailed as follows.
Engine Options
XQL Engine
XML-QL Engine
Whatever Engine
Selected Engine
Query Processing
Query Editor Mapping Definition
Administrator
End-User
Conceptual,
Logical and
Physical Metadata
Information
Mapping
XML Data Source
XML
XML
XML
Query
Information
(Re)Mapping
XML
Metada Manager
Developer
Extends the
schema to
construct a
new engine
XQOM Schema
XQOM Interface
Software
Component
Metadata
DOM /
XPath
Expression
File
Systems
XQOM Query
Expression
XML Conceptual
Data/Metada
Query
Expression
XML Data
Figure 1: XQOM Architecture.
2.1.1 XQOM Administration Module
The administrator defines conceptual, logical and
physical worlds, explained below, which must be dis-
posed to query through the XQOM Schema. These
worlds are controlled by XQOM mapping process.
The administrator also defines the mapping between
conceptual world and several documents (i.e. phys-
ical documents). All documents involved in the
XQOM mapping process are stored in a local file sys-
tem to future searches. Mapping module is performed
by a XQOM functionality, called XQOM Map En-
gine, that is essential for the (re)mapping of XQOM
metadata in both administration and query modules.
We understand conceptual world as a common set
of definitions or nomenclatures created by adminis-
trator. This set evolves specific domains of rules in an
environment and it is collectively created. Concep-
tual models are just XML documents which represent
these domains through its hierarchical structure.
Physical world denotes documents created by some
people (e.g. paper, journal, magazine, book etc.).
The end-user must structure his/her documents taking
into account XML markups. After all, the document
must be sent to the administrator to storage in XQOM
Schema.
Logical world evolves mapping between concep-
tual document and physical document(s). The ad-
ministrator (i.e. a specialist in that information area)
must associate conceptual world metadata with phys-
ical world metadata. We emphasize that physical
documents are created by different users and, thus,
they can represent them with different XML markups.
This occurs because users are completely free to in-
vent their own markup nomenclatures.
The administrator’s role is fundamental to promote
a good operation of XQOM Schema. It is extremely
important that this individual be a specialist in the
area being mapped.
Metadata management is responsible for the con-
trol of administration module. Its goal is to pro-
vide mapping information as well to generate con-
ceptual, logical and physical documents, storing them
in the local file system. The physical document stor-
age is defined by the application that extends XQOM
Schema. The same process is valuable to search mod-
els or physical documents.
When a solicitation of mapping information is sent
to metadata manager process, a software component
is activated to attend this request. This software com-
ponent constructs Xpath/DOM expressions that will
be applied to XML metadata documents distributed
among the directories of the local file system. The re-
sults of mapping metadata are returned and redirected
to the metadata manager that sends them to the appli-
cation solicitant.
Using the mapping information as a starting point,
the administrator can create new models or update
them. These models are redirected to the XQOM
Schema by the administrator. Then metadata manager
process updates the conceptual and logical documents
in directories of file system.
2.1.2 XQOM Query Module
The end-user can execute searches to conceptual doc-
uments using XQOM Query Module. He or she per-
forms the queries through the XQOM objects spec-
ification process. The language generation process
(i.e. XQOM Interpreter) uses it to generate new query
languages. The XQOM mapping process is used by
XQOM Interpreter to generate XML query languages
to document of the “physical world”. These lan-
guages are submitted to the XML, which returns a
response. Each response is mapped again to the end-
user “conceptual world”.
XQOM Specification is another functionality of
WEBIST 2006 - WEB INTERFACES AND APPLICATIONS
470
XQOM Schema. It is also represented through
XQOM query objects that constitute the status of
search syntaxes to semi-structured data. The gram-
matical representation of the search, performed by the
end-user through the conceptual models, is stored in
XQOM object specification. These objects represent
a query grammar to semi-structured data.
XQOM Map Engine is responsible by mapping
the query objects of XQOM Specification to the cor-
responding XQOM query objects that represent the
physical document markups. XQOM Interpreter will
perform queries using these objects and it will return
a XML document. This will be transferred to XQOM
Map Engine to map it in corresponding conceptual
model to end-user.
XQOM Interpreter is responsible for the query lan-
guage generation through the query objects trans-
ferred from the XQOM mapping process. It trans-
forms these objects in a XML query language. From
this point, the process continues as discussed before.
We have observed that XQOM Map Engine and
XQOM Interpreter are the XQOM Schema function-
alities that it may be activated several times in a query.
This is possible because conceptual model can be as-
sociated to more than one physical document through
logical document.
The end-user is responsible for execution of the
query module. He or she accesses XQOM Schema
through the client-server application or the web appli-
cation. The query machine is the process responsible
for the query module management.
The end-user constructs XQOM expressions using
a query editor (i.e. XQOM Interface). The query ma-
chine process is activated to attend the request and it
calls the metadata manager to perform the XQOM ex-
pression mapping.
In this process, n XQOM query objects are trans-
ferred to the application that extends XQOM Schema,
which will generate n XML query languages. These
will be transferred to a class responsible for the link-
ing of the query language to a XML query processing
software or to a XML database.
The resultant XML documents are returned to the
query machine, which will require the metadata man-
ager a new mapping of XML physical documents in
the corresponding conceptual model. This model is
returned to query machine and, after all, to the initial
application. The end-user only will see a conceptual
result.
2.2 XQOM Query Objects
XQOM query objects are represented by grammatical
graph objects in which its status denotes syntaxes of
a query language to semi-structured data (Figure 2).
XQOM Schema has been inspired on DOM model
(Document Object Model), but XML documents are
not converted into XML objects defined by DOM
specification. The objects in XQOM Schema have
values defined by end-user and compiles them to a
specific XML query language.
In case of change in the persistence layer, it is only
necessary a driver change to generate a new query lan-
guage through the XQOM Schema. This driver is de-
fined through a class that compiles the objects of the
XQOM Schema to the corresponding database lan-
guage. The XQOM Schema implicitly calls this class
and its change will not affect the application that uses
the proposed schema.
Figure 2 represents the XML query object model
through the oriented and labeled graph. This repre-
sentation is based on the deterministic finite automata
(Aho et al., 1974; Aho et al., 1995; Du and KO, 2001;
Hopcroft et al., 2001).
A
create
XMLQuery
B
F
E
D
C
add
GroupBy
add
Having
add Sorts
add
ElementQuery
G
add
XMLElement
add
AttributeFunction
add
XMLFunction
R
Having inherits
Statements
S
add
XMLStatement
T
add
XMLToken
Q
add
OrderBy
G
ElementQuery
inherits
XMLElement
V
G
add
XMLElement
add
Restriction
U
add
Projection
add
Projection
add
Restriction
G
add
XMLElement
add
XMLAttribute
add
element
add
attribute
O
add
XMLElement
H
add
element
J L
add
ElementFunction
add
attribute
add
XMLAttribute
add
function
add
XMLFunction
add
XMLFunction
Restriction inherits
Statements
add
XMLStatement
add
Statements
add
Projection
add ElementQuery
add
ElementQuery
adiciona
variable |
operator |
value
add
XMLStatement
N P
K
M
I
W
add
OrderBy
convert into
ElementFunction
Figure 2: XQOM Query Objects used to test the XQOM
Schema.
The gray area of Figure 2 represents the query
objects used to test the query languages within the
XQOM Schema.
2.3 XQOM Algorithm
The following XQOM Algorithm describes the search
carried out through the XQOM Schema from the con-
ceptual model (or document) input and its query fil-
ters to the result based on XML document that also
consists of a conceptual document:
1. Define the structure of the conceptual model;
2. Establish the structure of the physical models;
3. Define the mapping between the conceptual and physical models;
4. Load the filters;
5. Configure the lexical analyzer based on the filters sent by XQOM Inter-
face;
6. While there exists physical model associated to logical model do:
(a) Run the lexical analyzer based on the filters sent by XQOM Interface;
(b) Run the query languages and store the XML results;
XML QUERY OBJECT MODEL: A GENERAL VIEW
471
7. Remap to only one conceptual model the XML results based on the defi-
nition of the logical models.
3 SIMULATION AND RESULTS
In this section, we present simulations’ performances
that have collaborated to validate the XQOM Schema
functioning process. These results have partially been
obtained through a non-visual query environment for
the queries homologation carried out in the XQOM
Schema.
The communication among the conceptual, logical
and physical models is composed of four layers (i.e.
interface, conceptual metadata, logical metadata and
physical metadata), which illustrates the XQOM map-
ping idea (Silvestre et al., 2005) .
The XQOM mapping process, depicted in Figure 3,
is basically described as an association between con-
ceptual metadata and physical metadata (i.e. XML
Files).
Figure 3 presents, in a general view, an instance
of the XQOM mapping used to simulate and evaluate
the XQOM Schema: three physical documents and a
conceptual model. They are create and stored by the
administrator. The associations between conceptual
and physical models, presented in Figure 3, represent
the logical model.
conceptual.xml
Publication
Author
Title
Year
book.xml
books/book/name
books/book/date/year
magazine.xml
magazine/topic
magazine/editor
magazine/year
paper.xml
papers/paper/author
papers/paper/topic
papers/paper/year
<Publication>
<Author/>
<Title/>
<Year/>
</Publication>
<books>
<book>
<name>Jorge Lins</name>
<date>
<day>08</day>
<month>08</month>
<year>2005</year>
</date>
</book>
<book>
<name>Marcelo M.</name>
<date>
<day>03</day>
<month>12</month>
<year>2003</year>
</date>
</book>
</books>
<papers>
<paper>
<author>Tom Zé</author>
<topic>Musica<topic>
<year>2005</year>
<page>7-13</page>
</paper>
<paper>
<author>Fábio</author>
<topic>UML</topic>
<year>2005</year>
<page>63</page>
</paper>
</papers>
<magazine>
<topic>Design</topic>
<editor>Paulo</editor>
<number>2</number>
<year>2005</year>
<month>07</month>
</magazine>
XML Metadata
XML Document
Association Flows
Physical Document
Conceptual Document
Figure 3: XQOM Mapping: Association between concep-
tual metadata and physical metadata (i.e. XML files).
4 CONCLUDING REMARKS
Some benefits from XQOM Schema are pointed out.
It will facilitate to query official documents, journals,
libraries, magazines etc. It will also contribute to the
growing up of Document Electronic Management ap-
plications used in organizations that needs to offer
their documental heritage for searching. These ben-
efits can be possible through the use of conceptual
models such as ontologies, which will facilitate the
search and retrieval of electronic documents.
As well, it is important to highlight that XQOM
Schema does not use any particular XML query lan-
guage, despite it can generates any language. This
fact turns it portable to other databases. Its portability
is granted among operational systems because it has
been developed in Java.
We point out a XQOM Schema limitation. There is
a great responsibility granted to the administrator and
end-user as well. They create the markups for the con-
ceptual documents and physical documents, respec-
tively. This can generate incorrect markups or physi-
cal documents. As a consequence, wrong results can
be returned. Finally, it is suggested as a future work
the realization of an interface evaluation in order to
improve the usability of the XQOM Interface.
REFERENCES
Aho, A. V., Hopcroft, J. E., and Ullman, J. D. (1974).
The Design and Analysis of Computer Algorithms.
Addison-Wesley, Reading.
Aho, A. V., Sethi, R., and Ullman, J. D. (1995). Compi-
ladores Princ
´
ıpios, T
´
ecnicas e Ferramentas. LTC, Rio
de Janeiro.
Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E.,
and Yergeau, F. (1997). Extensible Markup Language
(XML). on-line. XML Specification by W3C.
Du, D.-Z. and KO, K.-I. (2001). Problem Solving in Au-
tomata, Languages, and Complexity. John Wiley and
Sons, New York.
Graves, M. (2001). Designing XML Databases. Prentice
Hall.
Hopcroft, J. E., Motwani, R., and Ullman, J. D. (2001). In-
troduction to Automata Theory, Languages, and Com-
putation. Addison-Wesley, Reading, 2nd edition.
Research, A. L. (1999). XML-QL: A Query Language for
XML. on-line. Source AT&T for the XML-QL.
Robie, J., Lapp, J., and Schach, D. (1998). XML Query
Language (XQL). on-line. XQL Tutorial of the W3C.
Silvestre, F. R., Pereira, H. B. B., and Jorge, E. M. F. (2005).
Esquema XQOM de Consultas a Documentos XML:
An
´
alise Te
´
orica. In SUCESU’2005 - Congresso Na-
cional de Tecnologia de Informac¸
˜
ao e Comunicac¸
˜
ao,
Belo Horizonte, Brazil.
WEBIST 2006 - WEB INTERFACES AND APPLICATIONS
472