Augmenting Traditional Conceptual Models to Accommodate XML Structural Constructs.

Full text

Page 1

Augmenting Traditional Conceptual Models
to Accommodate XML Structural Constructs
Reema Al-Kamha, David W. Embley, and Stephen W. Liddle
Brigham Young University, Provo, Utah 84602, U.S.A.
{reema, embley}@cs.byu.edu, {liddle}@byu.edu
Abstract. Although it is possible to present XML Schema graphically,
such representations do not raise the level of abstraction for XML schemata
in the same way traditional conceptual models raise the level of abstrac-
tion for data schemata. Traditional conceptual models, on the other hand,
do not accommodate several XML Schema structures. Thus, there is a
need to enrich traditional conceptual models with new XML Schema
features. After establishing criteria for XML conceptual modeling, we
propose an enrichment to represent the XML features missing in tradi-
tional models. We argue that our solution can be adapted generally for
traditional conceptual models and show how it can be adapted for two
popular conceptual models.
1Introduction
Recently, many organizations have begun to store their data using XML, and
XML Schema has become the preeminent mechanism for describing valid XML
document structures. Moreover, the number of applications that use XML as
their native data model have increased. This increases the need for well-designed
XML data models and the need for a conceptual model for designing XML
schemas.
Several commercial tools provide support for graphically representing XML
Schema structures. Visual Studio .NET [10] from Microsoft, Stylus Studio [15]
from DataDirect Technologies, and XML Spy [14] from Altova all have their own
proprietary methods for graphically representing XML structures. Each of them
includes a graphical XML Schema editor that uses connected rectangular blocks
to present the schema. Although these products provide visual XML Schema
editing tools, they do not raise the level of abstraction because they only provide
a direct view of an XML Schema document. Thus, these graphical representations
do not serve the objective of conceptualizing XML Schema to be used in modeling
and design.
In systems modeling and design, traditional conceptual models have proven
to be quite successful for graphically representing data at a higher level of ab-
straction. Conceptual models represent components and their relationships to
other components in the system under study in a graphical way, at a conceptual
level of understanding. Popular conceptual models that achieve these objectives
are ER [3], extended ER models [16], and UML [2,17].

Page 2

2Reema Al-Kamha et al.
XML Schema, however, introduces a few features that are not explicitly sup-
ported in these and similar conceptual models. The most important of these
features include the ability to (1) order lists of concepts, (2) choose alternative
concepts from among several, (3) declare nested hierarchies of information, (4)
specify mixed content, and (5) use content from another data model.
The chapter makes the following contributions. First, it proposes conceptual
representation for XML content structures that are not explicitly present in tra-
ditional conceptual models. Second, based on the underlying idea of the proposed
representation, it suggests ways to represent missing XML content structures in
two of the most popular conceptual models, ER and UML.
We present the details of our contributions as follows. Section 2 lists crite-
ria an XML conceptual model should satisfy. Section 3 describes the structural
constructs in XML Schema that are missing in traditional conceptual models.
Section 4 explains how we model these features of XML Schema in a modeling
language we call Conceptual XML (C-XML). Section 5 compares our proposal
with other proposals for ways to extend some traditional conceptual models to
represent some XML features and shows how to adapt C-XML representations
for traditional conceptual models. Section 6 summarizes and draws conclusions.
2XML Modeling Criteria
Lists of requirements for XML conceptual models have been presented in [18],
[13], and [9]. Some of these requirements cover general goals of conceptual model-
ing, while others are specific to XML. General requirements include the following:
– Graphical notation. The notation should be graphical and should be user-
friendly [9,13,18].
– Formal foundation. The conceptual model should have a formal foundation
[9,13,18].
– Structure independence. The notation should ensure that the basics of the
conceptual model are not influenced by the underlying structure, but reflect
only the conceptual components of the data [9,13,18].
– Reflection of the mental model. The conceptual model must be consistent
with a designer’s mental conceptualization of objects and their interrelation-
ships [13]. For example, there should be no distinction between element and
attribute on the conceptual level, and hierarchies should not be required.
– N-ary relationship sets. The conceptual model should be able to represent
n-ary relationship sets at the conceptual level [9].
– Views. It should be possible to transform the model to present multiple user
views [9].
– Logical level mapping. There should be algorithms for mapping the concep-
tual modeling constructs to XML Schema [9,18].
– Constraints. The conceptual model should support common data constraints
such as cardinality and uniqueness constraints [13].
– Cardinality for all participants. The hierarchical structure of XML data re-
stricts the specification of cardinality constraints only to nested participants;

Page 3

Lecture Notes in Computer Science3
however, it should be possible to specify cardinality constraints for all par-
ticipants at the conceptual level [9].
– Ordering. The conceptual model should be able to order a list of concepts
[9,13].
– Irregular and heterogeneous structure. The conceptual model should intro-
duce constructs for modeling irregular and heterogeneous structure [9].
– Document-centric data. The conceptual model should be able to represent
the mixed content and open content that XML Schema provides [9,13,18].
3 Missing Modeling Constructs
In this section we give an overview of the structural constructs in XML Schema
that are missing in traditional conceptual models. We explain each and give a
motivating example, which we also use in later sections to illustrate conceptual
model augmentations.
The sequence structure specifies that the child concepts declared inside it
must appear in an XML document in the order declared. Each ordered child con-
cept can occur zero or more times within the sequence constrained by minOccurs
and maxOccurs attributes. Likewise, the entire sequence itself can occur zero or
more times. The default value for both minOccurs and maxOccurs is always
1. The sequence construct may include several types of child constructs: ele-
ment, group, choice, sequence, and any. Lines 15–23 in Figure 1 specify that in
a complying XML document an element School contains a sequence of required
SchoolName, SchoolAddress, and SchoolID elements, and an optional SchoolMas-
cot element.
The choice structure specifies that for each choice only one of the child con-
cepts declared within it can appear in an XML document. Each child concept in
the choice can occur zero or more times within the choice constrained by minOc-
curs and maxOccurs attributes. Likewise, the entire choice itself can occur zero
or more times. The default value for minOccurs and maxOccurs for both the
entire choice and the component children is 1. The choice construct may include
several types of child constructs: element, group, choice, sequence, and any. In
Figure 1, lines 47–55 specify that in a complying XML document an element
ContactInfo contains one or two choices, and each choice contains either one
PhoneNumber, one Email, or one Fax.
By default, structural constructs in XML Schema can contain child elements,
but not text. To allow mixed content (child elements and text), XML Schema
provides a mixed attribute that can be set to true. In Figure 1, lines 43–58 show
an example of mixed content for a complex type. Setting mixed to true enables
character data to appear between the child elements of RecommendationLetter
in a complying XML document. Thus, the content of RecommendationLetter
may, for example, be “<RecommendationLetter> <ProfessorName> Dr. Jones
</ProfessorName> recommends this student. Email <ContactInfo><Email>jones@
univ.edu </Email> </ContactInfo> with questions. </RecommendationLetter>”.
The any and anyAttribute structures of XML Schema let designers reuse
components from foreign schemata or namespaces. The any structure allows

Page 4

4Reema Al-Kamha et al.
1
2
3
4
5
6
7
8
9
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="StudentInfo">
<xs:complexType>
<xs:sequence>
<xs:choice>
<xs:element name="Name" type="xs:string"/>
<xs:sequence>
<xs:element name="FirstName" type="xs:string"/>
<xs:element name="MiddleName" type="xs:string" minOccurs="0" maxOccurs="2"/>
<xs:element name="LastName" type="xs:string"/>
</xs:sequence>
</xs:choice>
<xs:sequence maxOccurs="5">
<xs:element name="School">
<xs:complexType>
<xs:sequence>
<xs:element name="SchoolName" type="xs:string"/>
<xs:element name="SchoolAddress" type="xs:string"/>
<xs:element name="SchoolID" type="xs:string"/>
<xs:element name="SchoolMascot" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:key name="schoolKey">
<xs:selector xpath=".//School"/>
<xs:field xpath="SchoolName"/>
<xs:field xpath="SchoolAddress"/>
</xs:key>
<xs:key name="schoolIDKey">
<xs:selector xpath=".//School"/>
<xs:field xpath="SchoolID"/>
</xs:key>
</xs:element>
<xs:element name="GraduationDate" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="Month" type="xs:string"/>
<xs:element name="Year" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:element name="RecommendationLetter" minOccurs="0" maxOccurs="3">
<xs:complexType mixed="true">
<xs:all>
<xs:element name="ProfessorName" type="xs:string"/>
<xs:element name="ContactInfo">
<xs:complexType>
<xs:choice maxOccurs="2">
<xs:element name="PhoneNumber" type="xs:string"/>
<xs:element name="Email" type="xs:string"/>
<xs:element name="Fax" type="xs:string"/>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="StudentNumber" type="xs:ID" use="required"/>
<xs:anyAttribute namespace="##any"/>
</xs:complexType>
</xs:element>
</xs:schema>
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
Fig.1. More Example of Choice/Sequence Structures in XML Schema.

Page 5

Lecture Notes in Computer Science5
the insertion of any element belonging to a list of namespaces, and it can have
minOccurs and maxOccurs attributes to define the number of occurrences of
the any construct. The anyAttribute structure allows the insertion of any at-
tribute belonging to a list of namespaces. Both any and anyAttribute can have
namespace and processContents as attributes. The attribute namespace specifies
the namespaces that an XML validator examines to determine the validity of an
element in an XML document. The attribute processContents specifies how the
XML processor should handle validation against the elements specified by the
any or anyAttribute. In Figure 1, the any element in line 59 specifies that zero or
more elements from any other namespace can appear after the Recommendation-
Letter element. Further, the anyAttribute specification in line 62 indicates that
the StudentInfo element can have additional attributes from any namespace.
When processContents is strict, the XML processor must obtain the schema for
the required namespaces and validate the elements. When processContents is set
to lax, the XML processor attempts the same processing as for strict, but ignores
errors if validation fails. When processContents is skip, the XML processor does
not attempt to validate any elements from the specified namespaces.
In XML Schema, it is possible to nest structural constructs, thus forming
a hierarchy of nested constructs. In Figure 1, for example, StudentInfo has the
attributes StudentNumber and anyAttribute, and it also contains the following
structures in order: first, either a Name or a sequence of one FirstName, zero
to two MiddleName’s, and one LastName; second, one to five sequences such
that each sequence includes one SchoolName, one SchoolAddress, and an op-
tional GraduationDate (the GraduationDate itself contains a Month followed by
a Year); third, an element RecommendationLetter that has two elements, Pro-
fessorName and ContactInfo (ContactInfo in turn contains one to two choices
such that in each choice either PhoneNumber or Email or Fax is specified); and
fourth, an optional any element.
4C-XML
In this section we propose an enrichment to represent XML Schema content
structures that are usually missing in traditional conceptual models. Since hy-
pergraphs provide a general representation for conceptual models, we begin with
an augmented hypergraph whose vertices and edges are respectively object sets
and relationship sets, and whose augmentations consist of decorations that rep-
resent constraints. A hypergraph foundation is amenable to the requirements of
XML Schema, and thus this choice simplifies the correspondence between con-
ceptual models and XML Schema. We call our representation Conceptual XML
(C-XML).
We derive C-XML from OSM [5], a hypergraph-based conceptual model that
defines structure in terms of object sets (or concepts), relationship sets, and con-
straints over these object and relationship sets. Figure 2 shows a C-XML model
instance that corresponds to the XML schema of Figure 1. An object set with a
solid border indicates a nonlexical concept, a dashed border indicates a lexical