XML Schema Languages. Why a DDL for XML?

Transcription

1 XML Schema Languages 1 Why a DDL for XML? For old & well-know (but good!) reasons As a modeling tool: to describe the structure of information: entities, relationships... to share common descriptions between actors/applications to guide query formulation and application development For error detection & safety: to verify that documents comply to what the application expects to make sure that the application accesses valid data to enforce safe operations (e.g., don t do float arithmetic on trees!) to check that compositions of operations make sense For performances: to design storage (saving space, improving clustering, etc.) to process queries (algebraic laws, rewriting path expressions, etc.) 2 1 1

2 But XML Deals with New Needs XML data created from legacy repositories Need to capture schemas from heterogeneous sources Relational schemas: Simple but with integrity constraints Object-oriented schemas: Typed references, Inheritance... Document grammars: Regular expressions, mixed text and structure XML used on the Web, for data exchange Need to remain flexible Web sources: From strict schemas to well-formed documents (smooooothly...) Many applications use the same information: We should be able to type the same document in multiple ways 3 Main XML DDL Desiderata Object-oriented Richer set of Datatypes Can extend or restrict a type (derive new type definitions on the basis of old ones) Database-oriented Can define elements with null content Can specify element content as being unique and scope of uniqueness World Wide Web Oriented Namespaces Distributed Schema Can create equivalent elements - e.g., the student" element is equivalent to the «φοιτητής" element 4 2 2

3 XML Schema At a Glance u Describing atomic values integer, string, float, date, images, etc v Describing structures elements: tag-coupled approach vs. tag-decoupled approach attributes w Capturing more semantics identity, references, relationships intra or inter documents isa: notion of inheritance... x Simplifying schema reuse import/export abilities refinement of existing descriptions 5 Values in XML: Easy? DTD says it s easy: Recipe: #PCDATA = string I.e.: CDATA = other strings,... Everything is a string Unfortunately: Strings are not a panacea... Database research says it s easy: Recipe: Take a data model with atomic types Each value is in a different type... I.e.: Don t deal with syntax but data model Unfortunately: XML = file = syntax 6 3 3

4 Values in XML: Many Issues... Addressing numerous needs: float, string, int, date, URI, telephone number, gif, applet, etc. Living with XML 1.0 syntax The same lexical representation can correspond to several values <artifact><title>haystacks at Chailly</title> <artist>monet</artist> <date>1865</date><price>38000</price> </artifact> The same value can have several lexical representations <in_auction>true</in_auction> <in_auction>1</in_auction> binary formats (images, etc.) must be serialized in a portable way Compatible with other standards Compatible with internationalization World Wide Web! 7 XML Schema Part 2: Datatypes Defines 18 of built-in types (basic types) general purpose types types for compatibility with DTDs Relies on other existing standards whenever possible IEEE for floats UCS [ISO 10646] & Unicode for internationalization ISO 8601 for dates bin.base64: MIME-style Base64 encoded binary BLOB bin.hex: Hexadecimal digits representing octets Uuid: Hexadecimal digits representing octets, with optional embedded hyphens ("333C7BC4-460F-11D0-BC C7055A83 ) Gives the ability to define new types (derived types) Single lexical representation for many values? document is interpreted with respect to a given schema if no schema, the value is given the type string 8 4 4

5 XML Datatypes can be... Atomic Single indivisible value vs Complex Decomposable value Basic (or Primitive) Not defined in terms of other datatypes Derived Defined in terms of other datatypes Built-in Defined in the Schema spec (may be derived) User-generated Defined by individual schema designers Datatypes can be applied to both attribute values and #PCDATA element content 9 A value space Can be enumerated outright, defined axiomatically, etc. ( the common notion of an integer ) A lexical value space Different physical representations of the same value (1, 1.0, 1.00, etc.) Fundamental facets Cardinality, exactness, boundedness Constraining facets What are the actual boundaries? An XML Datatype has t True,

6 Datatypes: Base Types Base types cover essential needs classic values: string, boolean, float, double, decimal temporal values: timeduration, recurringduration binary values: binary Web-related types: urireference, Qname DTD types: ID, IDREF, ENTITY, NOTATION One value for several syntaxes Each base type has a set of values (value space) Values may have several lexical representations (lexical space) Equality and order are defined in terms of the value space 11 Built-in Base Types: Examples string Datatype Examples Notes Victor Hugo boolean true, false, 1,0 float 12, 12.00, 1.2E-2, INF mx2^e where m < 2^ <= e <= 104 double 12, 12.00, 1.2E-2, INF mx2^e where m < 2^ <= e <= 970 decimal 0, -0, 1.23, Arbitrary precision timeduration P29Y2MT1H30M1.3S 29 years, 2 months, 3 days, 1 hour, 30 minutes, 1.3 seconds recurringduration T19:05:00 August 29 th at 7.05pm every year urireference

7 Datatypes: Facets Each base type has facets (read: properties) Some facets are fundamentals equality, order bounded, cardinality, numeric Some facets are constraining length, minlength, maxlength: for string, binary or lists maxinclusive, maxexclusive, mininclusive, minexclusive precision, scale: for decimal numbers encoding: hex or base64 for binary enumeration, pattern: for strings duration, period : for time, dates 13 Datatypes: Derived Types One can derive types by restriction of facets One can derive types by list XML Schema offers predefined derived types integer, non-positive-integer, int, date, year, century, time-instant, language, etc. <xsd:simpletype name= integer' base= xsd:decimal'> <scale value='0'/></xsd:simpletype> <xsd:simpletype name= int' base= xsd:integer'> <maxinclusive value= '/> <mininclusive value= /></xsd:simpletype> IDREFS, NMTOKENS, ENTITIES, etc. <xsd:simpletype name= IDREFS' base= xsd:idref derivedby= xsd:list />

8 Built-in Derived Types: Examples Derived Types Notes normalizedstring strings not containing carriage return (#xd), line feed (#xa),tab (#x9) chars token strings not containing line feed (#xa) tab (#x9) chars, not having leading/ trailing spaces (#x20) and internal sequences of two or more spaces language any valid xml:lang value, e.g.,en,fr,.. NMTOKEN "house barn yard" Name "hello-there" NCName part (no namespace qualifier) IDREFS List of IDREF ENTITIES List of ENTITITY integer decimal with 0 scale int integer > and < nonnegativeinteger zero to infinity integer positiveinteger one to infinity integer negativeinteger negative infinity to zero integer nonpositiveinteger negative infinity to negative one long integer > and < short int > and < byte short > -128 and < Classifying XML Datatypes primitive Built-in XML Types derived Built-in XML types user-derived XML Schema types derived atomic list union atomic list union

9 Now You Can Practice... Using a range facet <xsd:simpletype name= auctionprice' base= xsd:decimal'> <mininclusive value='10'/> </xsd:simpletype> Using an enumeration facet <xsd:simpletype name= artifactkind' base= xsd:string'> <xsd:enumeration value= Painting"/> <xsd:enumeration value= Sculpture"/>... </xsd:simpletype> Using a pattern facet <xsd:simpletype name= isbn base= xsd:string > <xsd:pattern value= ISBN \d{10}"/></xsd:simpletype> Using a list type <xsd:simpletype name= auctions base= auctionprice derivedby= xsd:list /> etc. 17 Regural Expression Chapter \d Chapter 1 a*b [xyz]b a?b b, ab a+b [a-c]x [a-c]x [-ac]x b, ab, aab, aaab, xb, yb, zb Example String Regular Expressions: Pattern Examples ab, aab, aaab, ax, bx, cx ax, bx, cx -x, ax, cx [ac-] ax, cx, -x [^0-9]x any non-digit char followed by x \dx digit char followed by x Chapter\s\d Chapter followed by a blank followed by a digit ho{2} there hoho there (ho\s){2} there ho ho there.abc any char followed by abc (a b)+x ax, bx, aax, bbx, abx, bax,... [a-c]x ax, bx, cx a{1,3}x ax, aax, aaax a{2,}x aax, aaax, aaaax, \w\s\w word (alphanumeric plus dash) followed by a space followed by a word

10 XML Schema Datatypes: Overview 19 Describing XML Structures element names with the names themselves: artifact, title, etc. possibly with wildcards: ~ = any tag,!a = not a, etc. element children using regular expressions element attributes unordered attribute-value pairs Main Question: status of types does the tag determines the type? tag-coupled types vs. tag-decoupled types

11 Coupled Types Approach taken by DTDs two elements with same name have always same type children = regular expression over elements <!ELEMENT artifact (title,artist?,price,date?,dimensions?)> <!ELEMENT title (#PCDATA)>... <!ELEMENT artist (name,nationality) <!ELEMENT name (first, last)> <!ELEMENT first (#PCDATA)>... Properties equivalent to context-free grammars easy to parse: => no depth look-ahead (1-unambuiguity) no closure under union, no local names allowed cannot fully capture relational, object-oriented schemas 21 Decoupled Types Approach taken by YAT, XDuce, lotos, etc. types are decoupled from element names children are defined by regular expressions over types type Artifact= artifact[title,artist?,price,date?,dimensions?] type Title = title [ String ] type Artist = artist [ Name, Nationality ] type Name = name [ first [ String ], last [ String ] ]... different types can have the same tag type PName = name [ String ] Properties equivalent to regular tree grammars closure properties (intersection, complement, union...) more precise type for documents and queries harder to parse (might require look-ahead and backtracking)

12 Decoupled Types They are simple to define basic entities: datatypes, tags, type names one construct : types schema ::= type type_name = type... type ::= String Boolean... (* datatypes *) type_name (* type name *) tag [ type ] (* element *) ~ [ type ] (* element with wild card *) type, type (* sequence *) type type (* union *) type* (* kleene star *) type? (* optional *) 23 Decoupled Types They can easily describe mixed content type Section = section [ title [ String ], Body ] type Body = content [ (b [ Body ] footnote [ String ] Section String)* ] They can easily describe all well-formed documents type UrScalar = (String Boolean Float Double...) type UrTree = UrScalar ~[ UrTree* ]

13 Decoupled Types They support a notion of subtyping via inclusion type Body2 = content [ String, (b [ String ] footnote [ String ] String)*, Section* ] Body2 <: Body <: UrTree all documents of type Body2 are also of type Body and UrTree But they can be ambiguous type Section2 = section [ title [ String ], Body2*, Body* ] deciding between Body and Body2 can be expensive 25 Decoupled Types & Full XML How do you describe attributes? type Book = book [ String ], Title, Author+, Price, Publisher, Section, Conclusion? ] but attributes are unordered, without duplicates they do not interact with the children of the element they cannot contain complex values How do you describe references? Like in object schemas: type Book = book [title [ String ], &Author+, &Publisher ] type Author = author [ name [ first [ String ],last [ String ] ] ] type Publisher = publisher [ name [ String ] ] but it s even harder to parse because of cycles [Beeri Milo 1999]

14 What about XML Schema? Tries to get the expressive power of decoupled types + the ease of parsing of coupled types Plus advanced features: subtyping, constraints... Deals with all the specifics of XML + XML Schema Syntax is in XML! <xsd:element name= book > <xsd:complextype> <xsd:element name= title" type="xsd:string"/> <xsd:element name= author maxoccurs= unbounded > <xsd:complextype> <xsd:element name= first type= xsd:string /> <xsd:element name= last type= xsd:string /> </xsd:complextype> </xsd:element>... </xsd:complextype> </xsd:element> 27 Element & Attribute Declarations Elements ~ associate element names to types have a name and are described by a type <xsd:element name= title" type="xsd:string"/> title [String] <xsd:element name= affiliation type= Publisher /> affiliation Attributes [ Publisher ~ associate ] attribute names to types have a name and contain an atomic value can be required or optional can only appear inside elements (through complex types) <xsd:attribute name= price type="xsd:string" use= [ String ]? <xsd:attribute name= auctionhistory type="auctions" [ Auctions] type Auctions = Decimal*

15 Model Groups Defines content models (i.e., type for the children of an element) ~ equivalent to regular expressions over elements <xsd:sequence> title[title],price[price] <xsd:element name= title" type= Title"/> <xsd:element name= price" type= Price"/> </xsd:sequence> <xsd:choice> ( publisher[publisher] editor[author] ) <xsd:element name= publisher type= Publisher /> <xsd:element name= editor type= Author /> </xsd:choice> <xsd:sequence minoccurs= 0 maxoccurs= unbounded > book[ Book ]* <xsd:element name = book type= Book > </xsd:sequence> <xsd:all> (title[title],price[price]) (price[price],title[title]) <xsd:element name= title" type= Title"/> <xsd:element name= price" type= Price"/> </xsd:all> 29 Complex Type Definitions they can contain a content model and attribute declarations The attribute declarations always come last, after the element declarations <xsd:complextype name= Book > type Book [String], <xsd:sequence> title [String], author[authorname]+ <xsd:element name= title" type="xsd:string"/> <xsd:element name= author maxoccurs= unbounded </xsd:sequence> they can be empty type= AuthorName /> <xsd:attribute name= isbn type= xsd:string/> </xsd:complextype> </xsd:complextype name= RefBib content= empty > <xsd:attribute name = refto type= xsd:idref /> </xsd:complextype> type RefBib [ &UrTree ]

16 Complex Type Definitions they can be recursive they can be mixed (i.e., strings + sub elements) <xsd:complextype name= Body content= mixed > <element name = b type= Body minoccurs= 0 maxoccurs= unbounded /> </xsd:complextype> type Body = (b [ Body ] String)* they may allow for null content <xsd:element name= AuthorName"> <xsd:complextype> <element name= first" type="xsd:string"/> <element name="middle type="xsd:string nullable="true"/> <element name= last" type="xsd:string"/> </xsd:complextype> </xsd:element> first[string],middle[string?],last[string] 31 The Any Element/ Attribute Type The any element allows any well-formed XML <xsd:element name="free-form"> <xsd:complextype> <xsd:any/> </xsd:complextype> </xsd:element> <free-form> <comment source= Vassilis">This is great!</comment> </free-form> The anyattribute allows any attribute <xsd:element name="free-form"> <xsd:complextype content="empty"> <xsd:anyattribute/> </xsd:complextype> </xsd:element> <free-form comment="this is great"/>

17 The UrTree Type The UrTree is the source for all types which do not specify a value for the source attribute It is the type for all elements which do not specify a type: Example <element name="foo"/> <xsd:complextype name= UrTree" content="mixed"> <xsd: any mininclusion="0" maxinclusion="*"/> <xsd:anyattribute/> </xsd:complextype> 33 Some Interactions Among Features Local element restrictions local elements with same name can have different type <xsd:element name= author > <xsd:complextype> <xsd:element name= name type= AuthorName /> </xsd:complextype> </xsd:element> type Author = author [ name [ AuthorName ] ] <xsd:element name= publisher"/> <xsd:complextype> <xsd:element name= name" type="xsd:string"/>... </xsd:complextype> </xsd:element> type Publisher = publisher [ name [ String ] ]

18 Some Interactions Among Features but they must have the same type among siblings <xsd:complextype name= Names > <xsd:element name= name type = AuthorName /> <xsd:element name= name type = xsd:string minoccurs = 0 /> <xsd:complextype> type Names= name [ AuthorName ], name [ String ]? When do you use the complextype element and when do you use the datatype element? Use complextype when there are elements and/or attributes Use datatype when it is a primitive type (string, integer, etc) To be simple or not to be simple... <internationalprice currency='eu'>423.46</internationalprice> requires a complextype defined by extension over decimals 35 Integrity Constraints ICs come from relational practical view-point: key & foreign key constraints Book(isbn, title, price, publisher) :isbn is a key for the relation Book Author(authorid, first, last, affiliation) :authorid and first,last are both keys for the relation Author Wrote(isbn,authorid) :isbn and authorid are foreign keys to Book and Author theoretical view-point: functional & inclusion dependencies studied in depth in the literature Many useful applications of ICs used to preserve information when mapping ER model to relational used for safety and verification (e.g., controlling updates) used for optimization (e.g., dropping useless joins)

19 ID/IDREF Mechanism in DTDs DTDs provided the ID/IDREF attribute datatypes for uniqueness Very simple ICs to model identity and references <!ELEMENT book (title, author+, price, publisher, section, bibliography?)> <!ATTLIST book isbn ID #required> <!ELEMENT title (#PCDATA)> <!ELEMENT publisher (name, address)> <!ATTLIST publisher sticker ID #required> <!ELEMENT bibliography EMPTY> <!ATTLIST bibliography refs IDREFS #implied> ID attributes must have distinct values they identify elements uniquely in a document but: they enforce uniqueness on both publisher s stickers and book s isbns! IDREF attributes must have values from ID attributes they can capture references to other elements but: they allow refs to point to publishers! 37 Uniqueness vs Key Key: an element which is defined to be a key must always be present (minoccurs must be greater than zero) be non-nullable (i.e., nullable="false") be unique within an element scope Key implies unique, but unique does not imply key XML Schema has much enhanced uniqueness capabilities: enables you to define element content to be unique enables you to define non-id attributes to be unique enables you to define a combination of element content and attributes to be unique enables you to distinguish between unique and key enables you to declare the scope of the document over which something is unique

20 Adding Constraints to DTDs We can replace IDs by real keys: book.isbn -> book isbn is a key for the relation book publisher.sticker -> publisher sticker is a key for the relation publisher author.authorid -> author authorid is a key for the relation author wrote.isbn,wrote.authorid -> wrote isbn and authorid are a key for the relation wrote We can replace IDREFs by real foreign keys biblio.refs <= book.isbn refs is a multi-valued foreign key from biblio to book wrote.isbn <= book.isbn isbn is a foreign key from wrote to book wrote.authorid<= author.authorid authorid is foreign key from wrote to author 39 Constraints in XML Schema XML Schema can define powerful constraints using XPath expressions One can define keys: <key name= Isbn"> <selector>books/book</selector> <field>@isbn</field> </key> <key name= Publisher"> <selector>books/book/publisher</selector> <field>@sticker</field> </key> the selector gives the document scope on which the constraint applies the field gives the unique tag or attribute content One can define foreign keys: <keyref refer= Isbn"> <selector>books/book/biblio</selector> <field>@refs</field> </keyref>

21 Constraints in XML Schema One can define unique combinations of values: <unique name= wroteunique"> <selector>books/book/author/wrote</selector> </unique> The key/keyref/unique elements may be placed anywhere in a schema Where you place them determines the scope of the uniqueness <selector>books</selector>: we are stating that in an instance document the uniqueness is with respect to the entire books document <selector>books/book/</selector>: uniqueness will have as scope just the book element. Thus, over the entire instance books document there may be repeats, but within any book element it will be unique 41 XML Schema Constraints: Research Issues [Fan et al 2000] show that reasoning with simple ICs on DTDs is decidable in practical cases: unary keys, unary (multi-valued) foreign keys, inverse constraints candidate keys and foreign keys Many open issues is XPath too powerful for reasoning (predicates, function calls?) which notion of equality is used? interaction between ICs and structural constraints?

22 Reusing Schemas Many benefits sharing existing definitions faster development Traditional techniques for schema reuse: some notion of import and the ability to resolve name conflicts Import Person, Company from StdClass class Person class Company tuple(name : tuple(first : string, tuple(name: string) last : string )) inheritance, based on subtyping class Author inherit Person class Publisher inherit Company tuple(affiliation: Publisher) tuple(address: string) tuple(first:string,last:string,affiliation:publisher) <: tuple(first:string,last:string) tuple(name:string, address: string) <: tuple(name:string) We need means to access schemas over the Web ~ namespaces 43 Using Namespaces in XML Schema A given XML Schema defines a set of new names The names defined in a schema are said to belong to its target namespace Definitions and declarations in a schema can refer to names that may belong to other namespaces We refer to those namespaces as source namespaces Each schema has one target namespace and possibly many source namespaces In fact, every name in a given schema belongs to some namespace The names for the namespaces can be fairly long, but they can be abbreviated with the syntax of xmlns declaration in the XML Schema document

23 Reusing XML Schemas: Including Types Means to include types in your schema from other schemas access and import though URIs (all must have the same namespace) equivalent as to create all types directly into the containing schema name conflict resolution based on user responsibility Book.xsd Company.xsd <schema xmlns=" targetnamespace=" xmlns:mybib=" <include schemalocation=" <include schemalocation=" </schema> Biblio.xsd 45 Reusing XML Schemas: Importing Types Means to import types in your schema from other schemas access and import though URIs allows you to reference types in another namespace name conflict resolution based on namespaces <schema xmlns=" targetnamespace= xmlns:html=" xmlns:mybib=" <import namespace=" schemalocation=" </schema> Biblio.xsd

24 Reusing XML Schemas: Extending Types Extension allows to add new fields in a complex type ~ inheritance <xsd:complextype name= ContactAuthor" base= Author" derivedby="extension"> <xsd:element name= telephone" type= xsd:string"/> </xsd:complextype> Now you can use both types but you might need to mark the data with xsi:type attributes <author xsi:type= Author > <name> <first>serge</first><last>abiteboul</last> </name> <affiliation>inria</affiliation> </author> <author xsi:type= ContactAuthor > <name> <first>vassilis</first><last>christophides</last></name> <affiliation>ics-forth</affiliation> <telephone> </telephone> </author> you cannot export the document without its type anymore Reusing XML Schemas: Restricting Types Restricts the scope of a type definition ~ set inclusion <xsd:element name= book2 base= book derivedby= restriction > <xsd:complextype> <xsd:element name= title" type="xsd:string"/> <xsd:element name= author minoccurs= 2 maxoccurs= 10 />... </xsd:complextype> </xsd:element> Spirit is to allow: smaller datatypes narrowed range for sequences t{n,m} < t{n,m } iff n>n && m<m reduced alternative t1 < (t1 t2) propagation of restriction t1 < t1 implies t1 < (t1 t2)

25 Reusing XML Schemas: Equivalence Classes Allows to define elements that can be used in place of other elements <element name= contact type= ContactAuthor equivclass= author'/> allow an element named contact to be used whenever an author element is expected <author> <name> <first>serge</first> <last>abiteboul</last> </name> <affiliation>inria</affiliation> </author> <contact> <name> <first>vassilis</first> <last>christophides</last> </name> <affiliation>ics-forth</affiliation> <telephone> </telephone> </contact> the corresponding type can be a derived type of course, equivalence classes are not based on equivalence!! 49 Reusing XML Schemas: Restricting Derivations Sometimes we may want to create a type and disallow all derivations of it, or just disallow extensions of it, or restrictions of it <xsd:complextype name="publication" final="#all" > This type cannot be extended nor restricted <xsd:complextype name="publication" final="restriction" > This type cannot be restricted <xsd:complextype name="publication" final="extended" > This type cannot be extended If you define a type to be exact, then other types may derive from it. However, in instances derived types may not be used in its stead <xsd:complextype name= author" exact="extension"> <xsd:element name= name" type= xsd:string"/> </xsd:complextype> <author xsi:type= ContactAuthor > <name> <first>vassilis</first><last>christophides</last></name> <affiliation>ics-forth</affiliation> <telephone> </telephone> </author>

26 Some Short-Comings Restriction is purely syntactic the following two types are not restrictions of one another! <xsd:sequence> a[a],(b[b],c[c]) <xsd:element name= a" type= A"/> <xsd:sequence> <xsd:element name= b" type= B"/> <xsd:element name= c" type= C"/> </xsd:sequence> </xsd:sequence> <xsd:sequence> (a[a],b[b]),c[c] <xsd:sequence> <xsd:element name= a" type= A"/> <xsd:element name= b" type= B"/> </xsd:sequence> <xsd:element name= c" type= C"/> </xsd:sequence> 51 Some Short-Comings Restriction and extension are not possible together: Person1 = person [ name [ UrTree ], age [ Int ] ] Person2 = person [ name [ String ], age [ Int ], address [ Address ] ]

27 Referencing a Schema in an XML Instance Document schemalocation= " targetnamespace= " Book.xml uses elements from namespace Book.xsd defines elements in namespace A schema defines a new vocabulary Instance documents use that new vocabulary 53 Multiple Levels of Checking Book.xml Book.xsd XMLSchema.dtd (schema-for-schemas) Validate that the xml document conforms to the rules described in Book.xsd Validate that Book.xsd is a valid schema document, i.e., it conforms to the rules described in the schema-for-schemas Schemas can be used to validate a document in two ways: Content Model Validation: Checks order and nesting of elements (similar to DTD validation) DataType Validation: Checks the element content for valid type and range

28 Namespaces in XML Schema: Overview 55 Validating an XML Schema Instance Document Validation can apply to the entire XML instance document, or to a single element Validating using" two schemas" <Biblio xmlns:book=" xmlns:company=" xmlns:xsi=" xsd:schemalocation= " <book:book> <book:title>data on the Web: From Relations to Semistructured Data and XML</book:Title> <book:author>serge Abiteboul</book:Author> <book:publisher>morgan Kaufmann</book:Publisher> </book:book> <company:affiliation> <person:name>inria</person:name> </company:affiliation> </Biblio>

29 (Almost) any Element/Attribute <any namespace="##other"/> allows any well-formed XML element, provided the element is in another namespace than the one we're defining <any namespace=" allows any well-formed XML element, provided it's from the specified namespace <any namespace="##targetnamespace"/> allows any well-formed XML element, provided it's from the namespace that we're defining <anyattribute namespace="##other"/> allows any attribute, provided the attribute is in another namespace than the one we're defining <anyattribute namespace=" allows any attribute, provided it's from the specified namespace <anyattribute namespace="##targetnamespace"/> allows any attribute, provided it's from the namespace that we're defining 57 DTD vs. XML Schema Features DTD XML Schema Integrat ion Type & Extensibili ElementsAttribute Syntax in XML No Yes Supporting Namespace No Yes include & import No Yes No. Built-in types User defined types No Yes Type domain constrints No Yes Explicit Null value No Yes Type extension No Yes Except Simple Type Attribute default falue Yes Yes Choice among attributes No No Optional/required Attr. Yes Yes Attribute domain constraints Partial Yes Element default value No Partial Element content model Yes Yes Choice among elements Yes Yes Min & Max Occurrence Partial Yes Unordered List No Yes

30 DTD vs. XML Schema Constraints Misc. Features DTD XML Schema Uniqueness for attributes Yes Yes Uniqueness for non-attributes No YES Key for attributes Yes Yes Key for non-attributes No YES Foreign key for attributes Partial Yes Foreign key for non-attributes No Yes Open model No Yes Documentation No Yes Emeded HTML No Yes Self-describability No Yes 59 Context-dependent XML Typing dealer dealer UsedCars NewCars UsedCars NewCars ad ad ad used ad new model year model DTDs cannot distinguish between used car ads and new car ads: different structure in difference contexts model year model Specialized DTDs allow ad to have different structure in different contexts

31 Specialized DTDs and XML Schemas Dealers UsedCars NewCars ad used ad new UsedCars NewCars ad used ad new model year model dealer dealer UsedCars NewCars UsedCars NewCars ad used ad new ad ad model year model model year model 61 Formal Foundations of XML Schemas Basic Questions on XML Schemas (~ Specialized DTDs) Validation: how hard? Expressive power: what can be defined? Closure properties: union, intersection, difference Complexity of manipulations Tool: powerful connection to tree automata! Theorem: DTDs with specialization define precisely the regular tree languages (over unranked trees) and so are equivalent to top-down and bottom-up non deterministic tree automata Closure properties: union, intersection, complement Algorithms for: validation wrt. DTD, decidable inclusion testing of DTDs, computing DTDs for union or intersection, etc. Static analysis

32 Regular Tree Grammars for XML Schemas Regular Tree Grammars (RTG): each function symbol has fixed arity Extended RTG (ERTG): arguments of a function symbol defined by a regular expression ERTG: G = (N, T, S, P) N is a set of non-terminals T is set of terminals S is set of start symbols P is a set of production rules of the form: A x (RE) where A in N, x in T, and RE is a regular expression of non-terminals Attributes are considered equivalent to elements Note: DTDs are local tree grammars imposing a restriction on RTG For every terminal symbol x, there is exactly one rule of the form: A x (RE) Advantage of tree-local: deterministic top-down, as well as, bottom-up parsing, with 1 look ahead 63 Where to Place XML Schemas DTD XML DTD schema Determinis.c top- down tree automata Tree automata Some bizarre restriction Inside an element, no two types with the same tag Closer to DTDs than to tree automata Efficient type validation

33 XML DDL: Summary XML Schemas are a tremendous advancement over DTDs: Enhanced datatypes 37+ versus 10 Can create your own datatypes Can define the lexical representation Written in XML enables use of XML tools Object-oriented flavor Can extend or restrict a type Can express sets - the child elements may occur in any order Can specify element content as being unique (keys on content) and uniqueness within a scope Can define multiple elements with the same name but different type Can define elements with null content Can create equivalent elements 65 XML DDL: Summary Complete but complex XML Schema specification... Many research work with interesting and complementary properties Yet no approach that reconciles all of the above And still some difficult problems to solve: concrete integrity constraint language that is tractable syntactic vs. semantics notion of subtyping? type inclusion is heavily used in Xduce [Hosoya et all 2000] instantiation [Cluet et al 1998] captures XML schema mechanisms, but is less powerful than inclusion graph schemas subsumption [Buneman et al 1997] captures a form of subtyping, but does not work on regular expression types for ordered data use of types for language typing use of types for query processing use of types for storage

34 Readings For formal semantics and expressive power of XML DTDs and Schemas read: Chapter 3 Web Data Management book The following material from the W3C Web page on XML XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes XML Schema Definition Language (XSD) 1.1 Part 1: Structures Check out the DTD of the XML Schema Specification /XMLSchema.dtd 67 Acknowledgements XML Data: From Research to Standards Daniela Florescu, Jerome Simeon Tutorial VLDB 2000 A Web Odyssey: from Codd to XML Victor Vianu, Invited Talk PODS 2001 XML Schemas Roger L. Costello online tutorial XML Technologies