Keys For XML Peter Buneman Susan Davidson Wenfei Fan Carmem Hara Wang Chiew Tan

Overview Motivation Definition of Keys Examples of Keys Value Equality Relative Keys Examples of Relative Keys Stronger Keys Examples of Stronger Keys Advantages Disadvantages Conclusion

Motivation Keys are used for citing parts of a document that is important Defects of XPath 1. Complex 2. Technical problems 3. Questions about the equivalence of XPath expressions

In the absence of keys the only way to identify a tuple is to give the entire tuple Smith Math2 - Jones Math2

Definition of Keys Key Specification is a pair (Q,{P 1,..., P n }) where Q is a path expression and {P 1,..., P n } is a set of simple path expressions. Path expression Q identifies a set of nodes target set on which the key constraint is to hold Set {P 1,..., P n } as the key paths. Example (person.employees, {name.firstname, name.lastname})

Formal Definition. A node n satisfies a key specification (Q,{P 1,..., P k }) if for any n1, n2 in n[[Q]], if for all, 1 <=i<= k, there exist z1 belonging to n1[[P i ]] and z2 belonging to n2[[P i ]] such that z 1 = v z 2, then n1 = n2. = v stands for value equality

Value Equality. Stands for equality of the "values" associated with nodes In XML schema nodes may have complex structure Example name may have a complex structure consisting of first-name and last-name subelements

Examples of Keys (_*.person, {id}) Any person element, if it has id subelements, is uniquely identified by the values of the id's. (person, {e}) Any two person nodes immediately under the root have different values (e is the empty path).

(employees, {}) An empty key. This means that the path employees, if it exists, is unique at the root. That is, there is at most one employees node immediately under the root. (_*,{id}) Any element that has id subelements is uniquely identified by the values of the id's

Relative Keys A document satisfies a relative key specification (Q, (Q',S)) if for all nodes n in [[Q]], n satisfies the key (Q',S). (Q, K) is a relative key if K is a key for every "sub- document" rooted at a node in [[Q]].

Examples of Relative Keys (bible.book.chapter, (verse, {number})) A verse number uniquely identifies a verse within a chapter. (bible.book, (chapter, {number})) Chapter numbers uniquely identify a chapter within a book. (bible, (book, {name})) If there is only one bible node immediately under the root, this is the same as specifying a key ( , (bible,{}))

Notation for relative keys The basic syntactic form is Q 1 {P1,...,P k 1 }.Q 2 {P1,...,Pk 2 }.....Q n {P1,...,Pk n } Example bible{}.book{name}.chapter{number}.verse{number }

Specifies:- ( , (bible,{})) (bible, (book, {name})) (bible.book, (chapter, {number})) (bible.book.chapter, (verse, {number}))

Stronger Keys The definition of keys we have adopted in this paper is quite weak To mirror the requirements imposed by a key in relational databases 1. Uniqueness of a key and 2. Equality of key values.

Definition. A node n satisfies a key specification (Q,{P 1,..., P k }) if for all n' in n[[Q]] and for all P i (1<= i<= k), P i is unique at n'. For any n 1, n 2 in n[[Q]], if n 1 [[P i ]] = v n 2 [[P i ]] (1<=i<= k) then n 1 = n 2.

Examples of Stronger Keys (_*.person, {id}) Any two person elements, no matter where they occur, have unique id subelements and differ on those elements. (person, {  }) The interpretation of this key remains unchanged under a strong key semantics.

(employees, {}) Again, the semantics of this key is the same with respect to the strong and weak key specifications. (_*,{k}) This requires that every element has a key k, including any element whose name is k.

Advantages More generic than XML schema. There is no direct notion of a relative key in XML- Schema but it is covered in this paper. The paper covers any alternative XML representations. 1. Tags expressed as attributes. 2. Introduce new type

Disadvantages Definition of target set :- XML Schema is from any arbitrary point where as this paper is from specific point Definition of key paths. There is no general method of checking whether two such specifications are equivalent in the proposal

In defining a key (Q,{P 1,..., P n }), the language used to describe the target path Q needs to be the same as the language used to define the key paths P 1,..., P n. One could choose a simpler language for key paths that is a sublanguage of the language for target paths.

Conclusion More generic way of representing keys The paper takes care of setbacks of XPath