CS561 Spring Mixed Content

Transcription

1 Mixed Content DTDs define mixed content by mixing #PCDATA into the content model DTDs always require mixed content to use the form (#PCDATA a b )* the occurrence of elements in mixed content cannot be controlled 1

2 Mixed Content XML Schema defines mixed content outside of the content model the content model is defined like an element content model the mixed attribute on the type marks the type as being mixed XML Schema mixed content can use all model groups 2

3 Mixed Content XML DTD <!ELEMENT A (#PCDATA B C )*> XML Schema <xs:element name= A" type= sometype"/> Valid Instance <A> text <C> <B> </B> text <C> </C> </C> text <B>text</B> </A> <xs:complextype name= sometype mixed="true"> <xs:choice maxoccurs="unbounded minoccurs="0"> <xs:element name= B type= sometype /> <xs:element name= C type= sometype /> </xs:choice> </xs:complextype> 3

4 Mixed Content XML Schema <xs:element name= A" type="mixedtype"/> <xs:complextype name="mixedtype mixed="true"> <xs:sequence maxoccurs="unbounded minoccurs="0"> <xs:element name= B type= sometype /> <xs:element name= C type= sometype /> </xs:sequence> </xs:complextype> XML instance <A> text <C> <B> </B> <C> </C> </C> <B> </B> </A> Not a valid instance: text can be interleaved with B and C elements but a B should always precede a C element! <A> text <B> text <B> </B> <C> </C> text <C> </C> </A> 4

5 Empty Content XML DTDs have a special keyword for empty elements no content model defined: the keyword EMPTY is used empty elements may still have attribute lists associated with them XML Schema empty types are defined implicitly there is no explicit keyword for defining an empty type if a type has no content model inside it, it is empty (it still may have attributes) 5

6 Empty Content XML DTD <!ELEMENT A EMPTY> <!ATTLIST A attr CDATA fixed US /> XML Schema <xsd:element name= A /> <xsd:complextype> <xsd:attribute name= attr type= xsd:string fixed= US /> </xsd:complextype> </xsd:element> 6

7 Complex Type Definitions they may allow for null content usage: represent null values from relational db <xsd:element name= name > <xsd:complextype> <element name= first" type="xsd:string"/> <element name="middle type="xsd:string nillable="true"/> <element name= last" type="xsd:string"/> </xsd:complextype> </xsd:element> not the same as empty! Valid Instance <name> <first>john</first> <middle xsi:nil= true /> <last>smith</last> </name> 7

8 xsd:anytype, xsd:any CS561 Spring 2009 An any element specifies that any well-formed XML is permissible in a type's content model <xs:element name= free_form > <xsd:complextype> <xsd:any/> </xsd:complextype> </xsd:element> Any well formed instance is valid! <free_form> <author>john</author> <comment>just a comment</author> </free_form> Can xsd:anytype and xsd:any be used interchangeably? No 8

9 xsd:anytype, xsd:any CS561 Spring 2009 The xsd:anytype does not impose any restriction on types <xsd:element name= price type= xsd:anytype /> price can have as value or any other well formed XML, independently of the types defined in the schema Can xsd:anytype and xsd:any be used interchangeably? No 9

10 xsd:anyattribute Similar to xsd:any xsd:anyattribute allows any attribute in the definition of a content model <xs:element name= free_form > <xsd:complextype> <xsd:anyattribute/> </xsd:complextype> </xsd:element> Any well formed instance is valid! <free_form attr= 1 /> <free_form title= some title /> 10

11 Some Interactions Among Features Elements defined in the context of different complex types (local elements) can have the same name but associated with different types! <xsd:element name= student ><xsd:complextype> <xsd:sequence> <xsd:element name= address type= xsd:string /> <xsd:sequence> </xsd:complextype></xsd:element> <xsd:element name= building /><xsd:complextype> <xs:sequence> <xsd:element name= address type= AddressType /> </xs:sequence> </xsd:complextype> </xsd:element> 11

12 Some Interactions Among Features When do you use the complextype element and when do you use the simpletype element? Use complextype to specify types for elements (when elements and/or attributes are considered) Use simpletype when it is a primitive type (string, integer, etc.) <internationalprice currency='eu'> </internationalprice> requires a complextype defined by extending over decimals 12

13 Some Interactions Among Features CS561 Spring 2009 requires a complextype defined by extending over decimals <internationalprice currency='eu'> </internationalprice> <xsd:element name="internationalprice"> <xsd:complextype> (complextype because it has <xsd:simplecontent> an attribute and a content) <xsd:extension base="xsd:decimal"> <xsd:attribute name="currency" type="xsd:string"/> </xsd:extension> (simplecontent because it contains </xsd:simplecontent> only character data and no elements) </xsd:complextype> </xsd:element> (extends decimal by adding an attribute) 13

14 Reusing types in XML Schema 14

15 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 inheritance, based on sub-typing 15

16 Reusing XML Schemas: Extending Types Extension allows to add new fields in a complex type: simulates inheritance <xsd:complextype name= Address > <xsd:sequence> <xsd:element name= street type= xsd:string /> <xsd:element name= city type= xsd:string /> <xsd:element name= country type= xsd:string /> </xsd:sequence> </xsd:complextype> 16

17 Reusing XML Schemas: Extending Types CS561 Spring 2009 Extension allows to add new fields in a complex type <xsd:complextype name= USAddress > <xsd:complexcontent> <xsd:extension base= Address > <xsd:sequence> <xsd:element name= state type= USState /> <xsd:element name= zip type= USZipCode /> </xsd:sequence> <xsd:attribute name= phone type= xsd:string /> </complexcontent> </xsd:complextype> Conceptually same as: 17

18 Reusing XML Schemas: Extending Types <xsd:complextype name= USAddress > <xsd:sequence> <xsd:element name= street type= xsd:string /> <xsd:element name= city type= xsd:string /> <xsd:element name= country type= xsd:string /> <xsd:element name= state type= USState /> <xsd:element name= zip type= USZipCode /> </xsd:sequence> Address content model elements and attributes for USAddress <xsd:attribute name= phone type= xsd:string /> </xsd:complextype> 18

19 Reusing XML Schemas: Extending Types Writing XML documents in the presence of derived types: using the xsi:type attribute at the instance level <nyaddress xsi:type= po:usaddress > <street>115w 82ND</street> <city>new York City</city> <country>usa</country> <state>ny</state> <address xsi:type= po:address > <street>115w 82ND</street> <city>new York City</city> <country>usa</country> </address> <zip>10024</zip> <phone> </phone> </nyaddress> 19

20 Reusing XML Schemas: Restricting Types It is possible to derive new types by restricting the content models of existing types similar to restricting simple types but must repeat the definition of the base type. CS561 Spring

21 Reusing XML Schemas: Restricting Types It is possible to derive new types by restricting the content models of existing types CS561 Spring 2009 <xsd:complextype name= USAddress"> <xsd:complexcontent> <xsd:restriction base= po:address > <xsd:sequence> <xsd:element name= country type= xsd:string fixed= USA /> include the definition of Address as is, but redefine the elements or attributes that have been restricted </xsd:restriction> </xsd:complexcontent> </xsd:complextype> 21

22 Reusing XML Schemas: Restricting Types CS561 Spring 2009 Idea: represent set inclusion Spirit is to allow: restricted datatypes e.g., the code for US states is not any string, but a two-letter word. narrowed range for sequences e.g., changing the min and max occurs for an element can be reduced to restricting facets of the XML Schema data types 22

23 Reusing XML Schemas: Restricting Derivations disallow all derivations of a type disallow extensions of a type disallow restrictions of a type CS561 Spring 2009 <xsd:complextype name= Address" final="#all" > This type cannot be extended nor restricted <xsd:complextype name= Address" final="extended" > This type cannot be extended <xsd:complextype name= Address" final="restriction" > This type cannot be restricted 23

24 Reusing XML Schemas: Restricting Derivations We can disallow a base type from being replaced by the types obtained from it by restriction or extension CS561 Spring 2009 <xsd:complextype name= Address" block= restriction"> <xsd:element name= street type= xsd:string"/> <xsd:element name= city type= xsd:string"/> <xsd:element name= country type= xsd:string"/> </xsd:complextype> <xsd:complextype name= PurchaseOrder"> <xsd:element name= shipto type= Address"/> </xsd:complextype> 24

25 Reusing XML Schemas: Restricting Derivations We can disallow a base type from being replaced by the types obtained from it by restriction or extension CS561 Spring 2009 <xsd:complextype name= PurchaseOrder"> <xsd:element name= shipto type= Address"/> </xsd:complextype> <xsd:element name= order type= PurchaseOrder /> <order> <shipto xsi:type= USAddress > <street>115w 82nd</street> <city>new York</last></name> <country>usa</country>. </shipto> </order> XML Schema Invalid Instance 25

26 Reusing XML Schema Types: Short Comings Restriction and Extension are not possible together cannot add elements/attributes to a type and restrict the definition of an existing sub-element of the type 26

27 Reusing XML Schema Types: Short Comings Restriction is purely syntactic, and is not taken into consideration directly when querying XML documents E.g., if asking for all addresses, one would expect to get the addresses whose type is US write it explicitly in the query! 27

28 DTD vs. XML Schema Features DTD XML Schema Integration w/ XML Type & Extensibility Attributes Elements Syntax in XML No Yes Supporting Namespace No Yes include & import No Yes No. Built-in types User defined types No Yes Type domain constraints 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 28

29 DTD vs. XML Schema CS561 Spring 2009 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 Embedded HTML No Yes Self-describability No Yes 29

30 Context-dependent XML Typing CS561 Spring 2009 DTDs do not allow one to use the same element but with different structure in different contexts Cannot distinguish between used car and new car postings: dealer UsedCars posting NewCars posting model year model 30

31 Context-dependent XML Typing CS561 Spring 2009 DTDs do not allow one to use the same element but with different structure in different contexts Specialized DTDs allow one to decouple the element names from types! dealer UsedCars posting used NewCars posting new model year model 31

32 Specialized DTDs A specialized DTD over an alphabet Σ is a pair (d, µ) with d a DTD defined over the types in Σ Σ µ: Σ Σ is a function that maps types to element names Dealer UsedCars NewCars UsedCars postingused NewCars postingnew postingused model year postingnew model µ(dealer)=dealer µ(usedcars)=usedcars µ(newcars)=newcars µ(postingused)=posting µ(postingnew)=posting 32

33 Specialized DTDs CS561 Spring 2009 dealer dealer UsedCars NewCars UsedCars NewCars posting used posting new posting posting model year model model year model 33

34 Formal Foundations of XML Schemas CS561 Spring 2009 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! 34

35 Formal Foundations of XML Schemas Theorem: Specialized DTDs define precisely the regular tree languages (over unranked trees) and so are equivalent to topdown 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 35

36 Regular Tree Grammars for XML Schemas CS561 Spring 2009 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 nonterminals 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 36

37 XML DDL: Summary In Semi-Structured Data graph theoretic data and schema are decoupled used in data processing In XML: 1. from grammar to object-oriented 2. schema wired with the data 3. emphasis on semantics for exchange Formal Expressive Power: 1. XML Schema can express precisely the regular tree languages (over unranked trees) 37

38 XML DDL: Summary CS561 Spring 2009 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 (integrity constraints and uniqueness constraints) Can define elements with the same name but different type Can define elements with null content Can create equivalent elements 38

39 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 sub-typing? 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 39