XML
Integrity Constraints
Mirian Halfeld Ferrari
European Master’s Program - Information Technologies for Business Intelligence
Mirian Halfeld Ferrari (IT4BI)
XML-IC
1 / 23
References and general information
Bibliographic notes
Béatrice Bouchou, Mírian Halfeld Ferrari Alves, Maria Adriana
Vidigal de Lima. Attribute Grammar for XML Integrity
Constraint Validation. DEXA (1) 2011 : 94-109
Ullman and Widom, A first course in database systems,
Prentice-Hall International, 1997. For some notions on relational
databases.
Béatrice Bouchou, Mírian Halfeld Ferrari, Maria Adriana Lima.
Contraintes d’intégrité pour XML. Visite guidée par une
syntaxe homogène. Technique et Science Informatiques 28(3) :
331-364 (2009)
Béatrice Bouchou, Ahmed Cheriat, Mírian Halfeld Ferrari,
Dominique Laurent, Maria Adriana Lima, Martin A. Musicante.
Efficient Constraint Validation for Updated XML Database.
Informatica (Slovenia) 31(3) : 285-309 (2007)
Mirian Halfeld Ferrari (IT4BI)
XML-IC
2 / 23
Introduction
Importance of integrity constraints
Integrity constraints are traditionally part of a schema
specification.
Integrity constraints are important in order to define some
semantics and to assure consistence.
Several constraint languages for XML have been proposed.
Different kinds of integrity constraints : keys (XKeys), foreign keys
(XFK), functional dependencies (XFD), inclusion dependencies
(XID)
Mirian Halfeld Ferrari (IT4BI)
XML-IC
3 / 23
To Express Integrity Constraints
Path, Patterns and Instances
Paths
A path for an XML tree t is defined by a sequence of tags or labels.
Our path languages : used to define integrity constraints over XML trees :
Path language PLs (defined by ρ ::= l | ρ/ρ | _).
Path language PL (defined by υ ::= [ ] | ρ | υ//ρ).
The language PLs describes a path in t, while PL is a generalization of PLs
including "//".
A path P is valid if it conforms to the syntax of PLs or PL and for all tag l ∈ P, if
l = data or l ∈ Σatt , then l is the last symbol in P.
Examples : /project/supplier /component or fac//student/courseTaken/courseCode
Mirian Halfeld Ferrari (IT4BI)
XML-IC
4 / 23
To Express Integrity Constraints
Path, Patterns and Instances
Path Instances
Let I = v1 / . . . /vn be a sequence of positions such that each vi is a direct
descendant of vi−1 in t.
I is an instance of P over t if and only if the sequence t(v1 )/ . . . /t(vn ) ∈ L(AP ).
AP the finite-state automaton defined according to P.
fac
fac
...
0
students
//
student
0.0
/
...
student
courseTaken
/
courseCode
/
id
St001
0.0.1.0
data
0.0.2.0
courseCode
courseTaken
0.0.2.1
deptName
0.0.4.0
courseCode
0.0.4.1
deptName
0.0.2.1.0
0.0.2.0.0
data
0.0.3.0.0
data
data
Computing
Math
XML-IC
0.0.4.0.0
data
0.0.5.0
data
Peter Smith
Maria
Caldas
C−BD−07S2
Mirian Halfeld Ferrari (IT4BI)
marriedTo
courseTaken
0.0.3.0
deptName
0.0.5
0.0.4
0.0.3
courseTaken
name
0.0.0.0
data
data
0.0.2
0.0.1
0.0.0
0.0.4.1.0
data
C−Theory−07S1 Computing
5 / 23
To Express Integrity Constraints
Path, Patterns and Instances
Patterns and pattern instances
A pattern is a finite set of prefix-closed paths in a tree t.
An instance of a pattern is defined by considering the longest common prefix
and an unique instance for it.
A set of paths : {fac//student/courseTaken/courseCode,
fac//student/courseTaken/deptName}))
Common prefix : fac//student/courseTaken
fac
This is not a pattern instance ! !
fac
//
/
data
...
0
students
student
/
courseTaken
/
/
courseCode deptName
0.0
...
student
/
data
0.0.0
id name
0.0.2
0.0.1
0.0.3
0.0.0.0
τC /P ,C /Q = [C − BD − 07S2, Computing ]
0.0.1.0
0.0.2.1
0.0.3.1
0.0.3.0
0.0.5
marriedTo
0.0.4.1
0.0.4.0
0.0.5.0
data
Peter Smith
Maria
Caldas
0.0.2.0.0
data
0.0.2.1.0
data
C−BD−07S2 Computing
Mirian Halfeld Ferrari (IT4BI)
courseTaken
data data courseCode deptName courseCode deptNamecourseCode deptName
St001
τC /P ,C /Q = [M − 1, Math]
0.0.2.0
0.0.4
courseTaken
courseTaken
XML-IC
data
M-1
0.0.3.0.0
data
Math
0.0.4.0.0
data
0.0.4.1.0
data
C−Theory−07S1 Computing
6 / 23
To Express Integrity Constraints
Equalities
Two types of equality
Value equality : two nodes are value equal when they are roots
of isomorphic sub-trees.
Node equality : two nodes are node equal when they are the
same position.
db
ε
1
0
project
project
0.0
Nodes 0.1 and 1.1
are value equal.
0.1
pname
0.0.0
data
Proj1
1.0
0.1.0
0.1.1
@sname
MSI
1.0.0
component
0.1.1.0
0.1.1.1
@cname
955X Neo
price
0.1.1.1.0
data
185,00
Mirian Halfeld Ferrari (IT4BI)
1.1
pname
supplier
XML-IC
data
Proj2
supplier
1.1.0
1.1.1
@sname
MSI
component
1.1.1.0
1.1.1.1
price
@cname
955X Neo
1.1.1.1.0
data
185,00
7 / 23
Different Integrity Constraints
Functional Dependencies
Functional Dependencies in Relational Databases
The relational case
In a relational database a functional dependency is defined as follows :
Let U be the set of attributes of a relation schema R. We usually write R[U].
Let X ⊆ U and A ∈ U. An instance I of R satisfies the functional dependency
X →A
when for all two tuples u and v if u[X ] = v [X ] then u[A] = v [A]
Given X → A, we say that X functionally determines A.
Consider the functional dependency Name, Year → Activity
Name
Year
Activity
Mario
2010
theatre
Diana
2010
theatre
Peter
2010 volleyball
Barbara 2011 volleyball
Mario
2011
football
Mirian Halfeld Ferrari (IT4BI)
XML-IC
8 / 23
Different Integrity Constraints
Functional Dependencies
XFD Syntax
An XML functional dependency (XFD) is an expression of the form :
Notation
γ = (C, ({P1 [E1 ], . . . , Pk [Ek ]} → Q [E]))
C, P1 . . . Pk and Q are path expressions.
Path C represents the context for the dependency verification.
{P1 , . . . , Pk } are the determinant paths of the XFD.
Q is the dependent path.
Symbols E1 , . . . , Ek represent the associated equality type.
Mirian Halfeld Ferrari (IT4BI)
XML-IC
9 / 23
Different Integrity Constraints
Functional Dependencies
XFD Semantics
Let
XML document T
XFD γ = (C, ({P1 [E1 ], . . . , Pk [Ek ]} → Q [E]))
Pattern P : {C/P1 , . . . ,C/Pk , C/Q}
XFD satisfaction
T |= γ if and only if for all two instances (I 1 , I 2 ) of pattern P in T that coincide at least
on their prefix C, we have :
τ 1 [C/P1 , . . . , C/Pk ] =Ei ,i∈[1...k ] τ 2 [C/P1 , . . . , C/Pk ] ⇒ τ 1 [C/Q] =E τ 2 [C/Q]
where τ 1 (resp. τ 2 ) is the tuple obtained from I 1 (resp. I 2 ).
Mirian Halfeld Ferrari (IT4BI)
XML-IC
10 / 23
Different Integrity Constraints
Functional Dependencies
XFD Example
γ1 : (db, ( {/project/supplier /@sname[V ],
/project/supplier /component/@cname[V ]}
→ /project/supplier /component/price[V ]) ))
db
ε
0
project
0.0
0.1
pname
0.0.0
.....
supplier
0.1.0
data
@sname
Proj1
MSI
0.1.1.0
@cname
[MSI , 955X Neo ,185,00 ]
,182,90 ]
[MSI , K8N
0.1.2
0.1.1
component
component
0.1.1.1
price
0.1.1.2
0.1.2.0
quantity
@cname
0.1.2.1
0.1.2.2
price
quantity
K8N
955X Neo
0.1.1.1.0
0.1.1.2.0
0.1.2.1.0
0.1.2.2.0
data
data
data
data
185,00
5
182,90
7
Mirian Halfeld Ferrari (IT4BI)
XML-IC
11 / 23
General Validation Method
General ideas
A general integrity constraint validation method
Our goal : integrity constraint validation on XML documents.
Our validation method : a grammarware (based on a grammar)
describing an XML document to which we associate attributes and
semantic rules.
Attribute grammar : the grammar is augmented by semantic rules
that define, for each integrity constraint, the verification process.
Mirian Halfeld Ferrari (IT4BI)
XML-IC
12 / 23
General Validation Method
General ideas
Building an attribute grammar
Attribute grammar : attach a set of semantic rules to each
production of a context-free grammar.
General CFG (context free grammar) to describe an XML tree.
Rule for the root element : ROOT → α1 . . . αm .
Rule for an internal element node : A → α1 . . . αm .
Rule for an element containing data and for an attribute : A → data.
Mirian Halfeld Ferrari (IT4BI)
XML-IC
13 / 23
General Validation Method
The case of XFD
FSA and TSAs for XFD
To model the paths of an XFD, we use finite-state automata (FSA) or transducers
(FST).
γ : (db/project, ( {/supplier /@sname[V ],/supplier /component/@cname[V ]}
→ /supplier /component/quantity [V ]) ))
M :
T’ :
e0
e3
db
supplier
e1
project
e2
@sname
e 6 | (V,1)
e4
component
T" :
Mirian Halfeld Ferrari (IT4BI)
e8
supplier
e9
component
XML-IC
e5
e10
@cname
quantity
e7 | (V,2)
e11 | V
14 / 23
General Validation Method
The case of XFD
Attribute Grammar for XFD Validation
Descending Direction : Inherited Attribute conf
conf is used at each node to indicate its role concerning an XFD
its value is a set of FSA configurations
all nodes are bound to a conf attribute, except data nodes
conf is an empty set when the node is not in any XFD path
Mirian Halfeld Ferrari (IT4BI)
XML-IC
15 / 23
General Validation Method
The case of XFD
Example : Descending direction
M:
e0
db
e1
project
e2
e6 | (V,1)
@sname
T’ :
e3 supplier e4
e5 @cname
component
T" :
e8
supplier
e9
component
e7
| (V,2)
e10 quantity e11 | V
db
conf = {M .e1 }
ǫ
0
project
conf = {M .e2 }
0.0
pname
0.0.0
0.1
conf = {}
supplier
0.1.0
conf = {T ′ .e5 }
data @sname
MSI
Proj1
0.1.1.0
0.1.1
conf = {T ′ .e4 , T ′′ .e9 }
0.1.2
conf = {T ′ .e6 , T ′′ .e10 }
component
conf = {T ′ .e7 }
@cname
955X Neo
0.1.1.2
quantity
conf = {T ′′ .e11 }
conf = {}
data
185,00
conf = {T ′ .e6 , T ′′ .e10 }
component
0.1.1.1
price
0.1.1.1.0
Mirian Halfeld Ferrari (IT4BI)
...
0.1.1.2.0
data
5
XML-IC
0.1.2.0
conf = {T ′ .e7 }
@cname
K8N
0.1.2.1
price
0.1.2.2
quantity
conf = {T ′′ .e11 }
conf = {}
0.1.2.1.0
data
182,90
0.1.2.2.0
data
7
16 / 23
General Validation Method
The case of XFD
Example : Descending direction
db
M:
e0
T’ :
e3 supplier e4
e1
project
e2
e5 | (V,1)
@sname
e6 @cname
component
T" :
e8
supplier
e9
component
e7
| (V,2)
e10 quantity e11 | V
db
conf = {M .e1 }
ǫ
0
project
conf = {M .e2 }
0.0
0.1
conf = {}
pname
0.0.0
data
Proj1
supplier
0.1.0
conf = {T ′ .e5 }
@sname
MSI
0.1.1.0
0.1.1
conf = {T ′ .e4 , T ′′ .e9 }
0.1.2
conf = {T ′ .e6 , T ′′ .e10 }
component
conf = {T ′ .e7 }
@cname
955X Neo
0.1.1.2
quantity
conf = {}
data
185,00
conf = {T ′ .e6 , T ′′ .e10 }
component
0.1.1.1
price
0.1.1.1.0
Mirian Halfeld Ferrari (IT4BI)
...
conf = {T ′′ .e11 }
0.1.2.0
conf = {T ′ .e7 }
@cname
K8N
0.1.2.1
price
0.1.2.1.0
0.1.1.2.0
data
5
XML-IC
0.1.2.2
quantity
conf = {T ′′ .e11 }
conf = {}
data
182,90
0.1.2.2.0
data
7
16 / 23
General Validation Method
The case of XFD
Example : Descending direction
M:
e0
db
e1
project
e2
e5 | (V,1)
@sname
T’ :
e3 supplier e4
e6 @cname
component
T" :
e8
supplier
e9
component
e10
quantity
e7
| (V,2)
e11 | V
db
conf = {M .e1 }
ǫ
0
project
conf = {M .e2 }
0.0
0.1
conf = {T ′ .e4 , T ′′ .e9 }
conf = {}
pname
0.0.0
data
Proj1
...
supplier
0.1.0
conf = {T ′ .e5 }
@sname
MSI
0.1.1.0
0.1.1
conf = {T ′ .e7 }
@cname
955X Neo
0.1.1.2
quantity
conf = {}
data
185,00
conf = {T ′ .e6 , T ′′ .e10 }
component
0.1.1.1
price
0.1.1.1.0
Mirian Halfeld Ferrari (IT4BI)
0.1.2
conf = {T ′ .e6 , T ′′ .e10 }
component
conf = {T ′′ .e11 }
0.1.2.0
conf = {T ′ .e7 }
@cname
K8N
0.1.2.1
price
0.1.2.1.0
0.1.1.2.0
data
5
XML-IC
0.1.2.2
quantity
conf = {T ′′ .e11 }
conf = {}
data
182,90
0.1.2.2.0
data
7
16 / 23
General Validation Method
The case of XFD
Example : Descending direction
db
M:
e0
T’ :
e3 supplier e4
e1
project
@sname
component
T" :
e8
supplier
e9
e2
e5 | (V,1)
e6 @cname
component e
10
quantity
e7 | (V,2)
e11 | V
db
conf = {M .e1 }
ǫ
0
project
conf = {M .e2 }
0.0
0.1
conf = {T ′ .e4 , T ′′ .e9 }
conf = {}
pname
0.0.0
data
Proj1
...
supplier
0.1.0
conf = {T ′ .e5 }
@sname
MSI
0.1.1.0
0.1.1
conf = {T ′ .e7 }
@cname
955X Neo
0.1.1.2
quantity
conf = {}
data
185,00
conf = {T ′ .e6 , T ′′ .e10 }
component
0.1.1.1
price
0.1.1.1.0
Mirian Halfeld Ferrari (IT4BI)
0.1.2
conf = {T ′ .e6 , T ′′ .e10 }
component
conf = {T ′′ .e11 }
0.1.2.0
conf = {T ′ .e7 }
@cname
K8N
0.1.2.1
price
0.1.2.1.0
0.1.1.2.0
data
5
XML-IC
0.1.2.2
quantity
conf = {T ′′ .e11 }
conf = {}
data
182,90
0.1.2.2.0
data
7
16 / 23
General Validation Method
The case of XFD
Example : Descending direction
M:
e0
db
e1
project
e2
e5 | (V,1)
@sname
T’ :
e3 supplier e4
component
T" :
e8
supplier
e9
component
e6 @cname
e7
e10 quantity
e11 | V
| (V,2)
db
conf = {M.e1 }
ǫ
0
project
conf = {M.e2 }
0.0
0.1
conf = {T ′ .e4 , T ′′ .e9 }
conf = {}
pname
0.0.0
data
Proj1
...
supplier
0.1.0
conf = {T ′ .e5 }
@sname
MSI
0.1.1.0
0.1.1
conf = {T ′ .e7 }
@cname
955X Neo
conf = {T ′ .e6 , T ′′ .e10 }
component
0.1.1.2
0.1.1.1
price
quantity
conf = {}
0.1.1.1.0
data
185,00
Mirian Halfeld Ferrari (IT4BI)
0.1.2
conf = {T ′ .e6 , T ′′ .e10 }
component
conf = {T ′′ .e11 }
0.1.2.0
conf = {T ′ .e7 }
@cname
K8N
0.1.2.1
price
0.1.2.1.0
0.1.1.2.0
data
5
XML-IC
0.1.2.2
quantity
conf = {T ′′ .e11 }
conf = {}
data
182,90
0.1.2.2.0
data
7
16 / 23
General Validation Method
The case of XFD
Example : Descending direction
db
M:
e0
T’ :
e3 supplier e4
e1
project
@sname
component
T" :
e8
supplier
e9
e2
e5 | (V,1)
e6 @cname
component e
10
quantity
e7 | (V,2)
e11 | V
db
conf = {M .e1 }
ǫ
0
project
conf = {M .e2 }
0.0
0.1
conf = {T ′ .e4 , T ′′ .e9 }
conf = {}
pname
0.0.0
data
Proj1
...
supplier
0.1.0
conf = {T ′ .e5 }
@sname
MSI
0.1.1.0
0.1.1
conf = {T ′ .e7 }
@cname
955X Neo
conf = {T ′ .e6 , T ′′ .e10 }
component
0.1.1.2
0.1.1.1
price
quantity
conf = {}
0.1.1.1.0
data
185,00
Mirian Halfeld Ferrari (IT4BI)
0.1.2
conf = {T ′ .e6 , T ′′ .e10 }
component
conf = {T ′′ .e11 }
0.1.2.0
conf = {T ′ .e7 }
@cname
K8N
0.1.2.1
price
0.1.2.1.0
0.1.1.2.0
data
5
XML-IC
0.1.2.2
quantity
conf = {T ′′ .e11 }
conf = {}
data
182,90
0.1.2.2.0
data
7
16 / 23
General Validation Method
The case of XFD
Example : Descending direction
M:
e0
db
project
e1
T’ :
e3 supplier e4
e6 @cname
component
T" :
e2
e5 | (V,1)
@sname
e8
supplier
e9
component
e10
quantity
e7
| (V,2)
e11 | V
db
conf = {M.e1 }
ǫ
0
project
conf = {M.e2 }
0.0
0.1
conf = {T ′ .e4 , T ′′ .e9 }
conf = {}
pname
0.0.0
...
supplier
0.1.0
conf = {T ′ .e5 }
data @sname
MSI
Proj1
0.1.1.0
0.1.1
conf = {T ′ .e7 }
@cname
955X Neo
conf = {T ′ .e6 , T ′′ .e10 }
component
0.1.1.2
0.1.1.1
price
data
185,00
0.1.2.0
quantity
conf = {}
0.1.1.1.0
Mirian Halfeld Ferrari (IT4BI)
0.1.2
conf = {T ′ .e6 , T ′′ .e10 }
component
conf = {T ′′ .e11 }
conf = {T ′ .e7 }
@cname
K8N
0.1.2.1
price
0.1.2.1.0
0.1.1.2.0
data
182,90
data
5
XML-IC
0.1.2.2
quantity
conf = {T ′′ .e11 }
conf = {}
0.1.2.2.0
data
7
16 / 23
General Validation Method
The case of XFD
Just an example of a rule in the attribute grammar
Production
ROOT → α1 . . . αm
Mirian Halfeld Ferrari (IT4BI)
Attributes
ROOT .conf := { M.q1 | δM (q0 , ROOT ) = q1 }
/* Inherited Attributes */
for each αi (1 ≤ i ≤ m) do
αi .conf := { M.q ′ | δM (q1 , αi ) = q ′ }
if (q1 ∈ FM ) then
αi .conf := αi .conf ∪ { T ′ .q1′ | δT ′ (q0′ , αi ) = q1′ }
∪ { T ′′ .q1′′ | δT ′′ (q0′′ , αi ) = q1′′ }
XML-IC
17 / 23
General Validation Method
The case of XFD
Attribute Grammar for XFD Validation
Ascending Direction : Synthesized Attributes c, inters, dc, dsj .
c carries the dependency validity (true or false) from context level
to the root.
inters gathers the values from the nodes that are in determinant
and dependent path intersections.
dsj and dc store the values needed to verify the dependency.
Mirian Halfeld Ferrari (IT4BI)
XML-IC
18 / 23
General Validation Method
The case of XFD
Example : Ascending direction
Computing synthesized attributes :
db
c =< true >
ǫ
0
project
c =< true >
...
0.1
0.0
inters = {<< MSI, 955XNeo >, 5 >, << MSI, K 8N >, 7 >}
supplier
pname
0.0.0
data
Proj1
0.1.0
ds1 =< MSI >
@fname
MSI
0.1.1.0
ds1 =< MSI >
0.1.1
component
0.1.1.1
ds2 =< 955XNeo >
@cname
955X Neo
price
0.1.1.1.0
0.1.1.2
0.1.2.0
dc =< 5 >
quantity
0.1.1.2.0
data
185,00
Mirian Halfeld Ferrari (IT4BI)
0.1.2
inters = {<< ǫ, 955XNeo >, 5 >}
ds2 =< 955XNeo >
dc =< 5 >
data
5
XML-IC
inters = {<< ǫ, K 8N >, 7 >}
ds2 =< K 8N >
dc =< 7 >
component
0.1.2.2
dc =< 7 >
0.1.2.1
ds2 =< K 8N >
@cname
K8N
price
0.1.2.1.0
data
182,90
quantity
0.1.2.2.0
data
7
19 / 23
General Validation Method
The case of XFD
Example : Ascending direction
Computing synthesized attributes :
db
c =< true >
ǫ
0
project
c =< true >
...
0.1
0.0
inters = {<< MSI, 955XNeo >, 5 >, << MSI, K 8N >, 7 >}
supplier
pname
0.0.0
0.1.0
ds1 =< MSI >
data @fname
Proj1
MSI
0.1.1.0
ds1 =< MSI >
0.1.1
component
0.1.1.1
ds2 =< 955XNeo >
@cname
955X Neo
price
0.1.1.1.0
0.1.1.2
0.1.2.0
dc =< 5 >
quantity
0.1.1.2.0
data
185,00
Mirian Halfeld Ferrari (IT4BI)
0.1.2
inters = {<< ǫ, 955XNeo >, 5 >}
ds2 =< 955XNeo >
dc =< 5 >
inters = {<< ǫ, K 8N >, 7 >}
ds2 =< K 8N >
dc =< 7 >
component
price
0.1.2.1.0
data
5
XML-IC
0.1.2.2
dc =< 7 >
0.1.2.1
ds2 =< K 8N >
@cname
K8N
data
182,90
quantity
0.1.2.2.0
data
7
19 / 23
General Validation Method
The case of XFD
Example : Ascending direction
Computing synthesized attributes :
db
c =< true >
ǫ
0
project
c =< true >
...
0.1
0.0
inters = {<< MSI, 955XNeo >, 5 >, << MSI, K 8N >, 7 >}
supplier
pname
0.0.0
data
Proj1
0.1.0
ds1 =< MSI >
@fname
MSI
0.1.1.0
ds1 =< MSI >
0.1.1
component
0.1.1.1
ds2 =< 955XNeo >
@cname
955X Neo
price
0.1.1.1.0
0.1.1.2
0.1.2.0
dc =< 5 >
quantity
0.1.1.2.0
data
185,00
Mirian Halfeld Ferrari (IT4BI)
0.1.2
inters = {<< ǫ, 955XNeo >, 5 >}
ds2 =< 955XNeo >
dc =< 5 >
data
5
XML-IC
inters = {<< ǫ, K 8N >, 7 >}
ds2 =< K 8N >
dc =< 7 >
component
0.1.2.2
dc =< 7 >
0.1.2.1
ds2 =< K 8N >
@cname
K8N
price
0.1.2.1.0
data
182,90
quantity
0.1.2.2.0
data
7
19 / 23
General Validation Method
The case of XFD
Example : Ascending direction
Computing synthesized attributes :
db
c =< true >
ǫ
0
project
c =< true >
...
0.1
0.0
inters = {<< MSI, 955XNeo >, 5 >, << MSI, K 8N >, 7 >}
supplier
pname
0.0.0
data
Proj1
0.1.0
ds1 =< MSI >
@fname
MSI
0.1.1.0
ds1 =< MSI >
0.1.1
component
0.1.1.1
ds2 =< 955XNeo >
@cname
955X Neo
price
0.1.1.1.0
0.1.1.2
0.1.2.0
dc =< 5 >
quantity
0.1.1.2.0
data
185,00
Mirian Halfeld Ferrari (IT4BI)
0.1.2
inters = {<< ǫ, 955XNeo >, 5 >}
ds2 =< 955XNeo >
dc =< 5 >
data
5
XML-IC
inters = {<< ǫ, K 8N >, 7 >}
ds2 =< K 8N >
dc =< 7 >
component
0.1.2.2
dc =< 7 >
0.1.2.1
ds2 =< K 8N >
@cname
K8N
price
0.1.2.1.0
data
182,90
quantity
0.1.2.2.0
data
7
19 / 23
General Validation Method
The case of XFD
Just an example of a rule in the attribute grammar
Production
A → data
Mirian Halfeld Ferrari (IT4BI)
Attributes
/* Synthesized Attributes */
for each configuration M.q in A.conf do
if (M = T ′ ) ∧ (q ∈ FT ′ )
y := λ′T ′ (q)
j := y .rank
if (y .equality = V )
then A.dsj := < value(t, data) >
else A.dsj := < value(t, A) >
if (M = T ′′ ) ∧ (q ∈ FT ′′ )
if (λ′′T ′′ (q) = V )
then A.dc := < value(t, data) >
else A.dc := < pos(t, A) >
XML-IC
20 / 23
General Validation Method
The case of XFD
XFD Validation Overview
xxxxxx
xxxxxx
xxxxxx
xxxxxx
xxxxxx
xxxxxx
xxxxxx
xxxxxx
xxxxxx
Validation using
xxxxxx
xxxxxx
Attribute Grammar
xxxxxx
TRUE / FALSE
(for each constraint)
XML Document
XFDs
InhAtt_Stack
SyntAtt_Stack
Validation_HTables
Auxiliary Data Structures
Mirian Halfeld Ferrari (IT4BI)
XML-IC
21 / 23
General Validation Method
The case of XFD
XFD Validation Overview : Auxiliary Structures
Mirian Halfeld Ferrari (IT4BI)
XML-IC
22 / 23
General Validation Method
Constr.
XFD
Overview of other Integrity constraints
FSA
Attributes
M, T and T ′
Inherit. : : conf
Synth. : c, inters, dsj , dc
(C, ({P1 , . . . , Pk }
⊆ {Q1 . . . Qk }))
M, T and T ′
XKeys
(C, (Tg, {P1 , . . . , Pk }))
AC , ATg et AP
Inherit. : : conf
Synth. : c, inters, dsj , dcj
Inherit. : conf
Synth. : c, tg et f
XFK
(C, (Tg R , {P1R , . . . , PkR })
⊆ (Tg, {P1 , . . . , Pk }))
AC , ARTg , ARP
XID
Path expression
(C, ({P1 [E1 ], . . . , Pk [Ek ]}
→ Q [E]))
Mirian Halfeld Ferrari (IT4BI)
XML-IC
Inherit : conf
Synth. : c, tg et f
23 / 23