Download presentation
Presentation is loading. Please wait.
1
XML Validation III Schemas
Robin Burke ECT 360
2
Outline Admin Namespaces review XML Schemas Break Data types Elements
Attributes Break Data types
3
Admin Due today Due next week Due 10/24 Project milestone #3
Document analysis Due next week Homework #3 Due 10/24 Milestone #4: Schema or DTD
4
Quiz
5
Assessment Homework – 35%
Participation (including in-class exercises and labs) – 15% Quizzes – 20% Final project – 30%
6
Namespaces A way to identify a set of labels
element / attribute names attribute values As belonging to a particular application Example course "title" html "title"
7
Namespace idea Associate a short prefix with an application
Use the prefix with a colon to "qualify" names html:title syll:title
8
Namespace idea, cont'd A namespace is an association between
a set of names a unique identifier (URI) a prefix used to identify them
9
Namespace declaration
Standalone <?xml:namespace ns=" prefix="book"?> Part of element <html xmlns=" in this case, no prefix <book:book xmlns:book="
10
Namespaces Essential if we must combine documents from different applications For example we want to define a new XML language using XML namespace for new language namespace for defining language
11
XML so far Languages defined by DTDs OK for text documents
contain text elements string attributes OK for text documents Not enough for Databases Business process integration Need data types
12
Solution XML Schema XML document becomes
Write language definition in XML More control over document contents XML document becomes a complex data type XML language definition becomes complex data type specification
13
XML Schema Always a separate document Written in XML
no internal option Written in XML very verbose Can be large and complex
14
Schemas and namespaces
A schema uses elements from one application the XML Schema language to define another Namespaces are necessary Namespaces apply to elements not values
15
Example 1, XML <grades assignment="Homework 1"> <grade>
<student id=" ">Jane Doe</student> <assigned-grade>A</assigned-grade> </grade> <student id=" ">John Doe</student> <assigned-grade>B</assigned-grade> </grades>
16
Example 1, DTD <!ELEMENT grades (grade*)> <!ATTLIST grades
assignment CDATA #IMPLIED> <!ELEMENT grade (student, assigned-grade)> <!ELEMENT student (#PCDATA)> <!ATTLIST student id CDATA #REQUIRED> <!ELEMENT assigned-grade (#PCDATA)>
17
Data types grades grade student assigned-grade is text
a collection of items of type grade can never have more than 40 students grade a structure containing a student and an assigned grade student a structure containing an id and some text probably should constrain the student id assigned-grade is text probably should constrain to A-D,F,I
18
Built-in types Part of the schema language Base types Derived types
19 fundamental types Examples: string, decimal Derived types 25 more types that use the base types Examples: ID, positiveInteger
19
Built-in types, cont'd
20
To declare an element Equivalent to type="string">
<xs:element name="assigned-grade" type="string"> Equivalent to <!ELEMENT assigned-grade (#PCDATA)>
21
Simple data type A renaming of an existing data type
<xs:element name="assigned-grade" type="xs:string"> Or a restriction of a existing type strings beginning with "A-D"
22
Complex datatype <xs:element name=“name”> <xs:complexType>
compositor element declarations attribute declarations </xs:complexType> </xs:element>
23
Compositor sequence choice all
24
Sequence compositor like "," in DTD DTD Schema
<!ELEMENT foo (bar, baz)> Schema <xs:element name="foo"> <xs:complexType> <xs:sequence> <xs:element ref="bar" /> <xs:element ref="baz" /> </xs:sequence> </xs:complexType> </xs:element>
25
Elements in sequences Can specify optional / # of occurrences ? * +
<xs:element ref="bar" minOccurs="0" type="xs:string"> * <xs:element ref="bar" minOccurs="0" maxOccurs="unbounded" /> + <xs:element ref="bar" minOccurs="1" maxOccurs="unbounded" /> What about... <xs:element ref="bar" minOccurs="2" maxOccurs="4" />
26
Choice compositor like "|" in DTD DTD Schema
<!ELEMENT foo (bar | baz)> Schema <xs:element name="foo"> <xs:complexType> <xs:choice> <xs:element ref="bar" /> <xs:element ref="baz" /> </xs:choice> </xs:complexType> </xs:element>
27
All compositor no simple DTD equivalent DTD Schema
<!ELEMENT foo ( (bar, baz?) | (baz, bar?) > Schema <xs:element name="foo"> <xs:complexType> <xs:all> <xs:element ref="bar" /> <xs:element ref="baz" /> </xs:all> </xs:complexType> </xs:element>
28
Nesting Compositors can be combined DTD Schema
<!ELEMENT foo ( (bar | baz) , (thud | grunt) )> Schema <xs:element name="foo"> <xs:complexType> <xs:sequence> <xs:choice> <xs:element ref="bar" /> <xs:element ref="baz" /> </xs:choice> <xs:element ref="thud" /> <xs:element ref="grunt" /> </xs:sequence> </xs:complexType> </xs:element>
29
Exercise <!ELEMENT personal-info (person-name, job-title)>
<!ELEMENT address (street, city, state, zip)> <!ELEMENT street (#PCDATA)>
30
Local naming Suppose we want to reuse an element name Example
different place in the structure Example <!ELEMENT url-catalog (link*)> <!ELEMENT link (link, description?)> not a legal DTD schema? legal local naming permitted maybe not wise, though
31
Using namespaces what namespace it is using Schema must say
to use schema namespace what namespace it is defining targetNamespace what namespace it is using Document must say that it is using the Schema Instance namespace what namespace(s) it is using what prefix(es) are used where to find the relevant schemas for each namespace
32
Ugly Schema root element Document root element
<xs:schema elementFormDefault="qualified" xmlns:xs=" targetNamespace=" xmlns=" Document root element <business-card xmlns=" xmlns:xsi=" xsi:schemaLocation=" biz-card.xsd">
33
Attributes DTD attribute types Schema Declaration
CDATA, enumeration, token Schema can be any of the basic or derived types can also be user-defined types Declaration <xs:attribute name="x" type="xs:string" use="required" default="abc" />
34
Attribute declaration
Part of complex type follows compositor (one exception) Declaration <xs:attribute name="foo" type="xs:positiveInteger" /> What if the attribute is a more complex type itself? we'll get to that
35
Exception: simple content
If an element has "simple content" no compositor used instead simpleContent element and extension to declare type of the content
36
Example <xs:element name="student"> <xs:complexType>
<!ELEMENT student (#PCDATA)> <!ATTLIST student id CDATA #REQUIRED> <xs:element name="student"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="id" type="xs:string" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
37
How to read this student is a complex type its content is simple
it is not simply a renaming of an existing type because of the attribute its content is simple being of only one type string but with an attribute id of type string which is required
38
Exercise <!ATTLIST personal-info id ID #IMPLIED>
<!ELEMENT contact (#PCDATA)> <!ATTLIST contact type ( | fax | phone | web) #REQUIRED> <!ELEMENT text (#PCDATA)> <!ATTLIST text type (endorsement | motto | services) #REQUIRED>
39
Named types We can name a complex type Example
use it wherever a built-in type would work Example <xs:complexType name="barBaz"> <xs:sequence> <xs:element ref="bar" /> <xs:element ref="baz" /> </xs:sequence> </xs:complexType> <xs:element name="foo" type="barBaz"/>
40
Built-in types Part of the schema language Base types Derived types
19 fundamental types Examples: string, decimal Derived types 25 more types that use the base types Examples: ID, positiveInteger
41
Built-in types, cont'd
42
User-defined types Any use of complexType can be turned into a user-defined type usually called "standalone" Simple types can be derived from the built-in types
43
Standalone types A type can stand outside of an element definition
must have a name <xs:complexType name="bar-n-baz"> <xs:sequence> <xs:element ref="bar" /> <xs:element ref="baz" /> </xs:sequence> </xs:complexType> Used in element definition <xs:element name="foo" type="bar-n-baz" />
44
Mixed content Can specify that an element has mixed content
<xs:complexType name="bar-n-baz" mixed="true"> <xs:sequence> <xs:element ref="bar" /> <xs:element ref="baz" /> </xs:sequence> </xs:complexType>
45
Mixed content, cont'd Schema cannot control where the text appears
If this is legal <foo>text here <bar>thud</bar><baz>grunt</baz></foo> So is this <foo><bar>thud</bar>more text<baz>grunt</baz>still more</foo>
46
Deriving types DTDs do not allow type restrictions
beyond enumeration, CDATA, token for attributes PCDATA for content Schemas have built-in types also capability to create your own
47
Derivation operations
list sequence of values union combine two types allowing either restriction placing limits on the legal values
48
List Must be separated by spaces
<xs:element name="partList"> <xs:simpleType> <xs:list itemType="partNo" /> </xs:simpleType> </xs:element> <partList>PN PN PQ </partList> Must be separated by spaces probably more useful to do this with document structure partList -> partNo*
49
Union Allows data of either type to be used Example Database situation
<xs:simpleType name="partNumberField"> <xs:union memberTypes="partNumberType noPartNum" /> </xs:simpleType> Database situation null is a possible value
50
Restriction Most useful
Allow design to state exactly what values are legal prices must be non-negative SSN must follow a certain pattern in-stock must yes or no etc.
51
Restriction, cont'd Restrict a base type
according to "facets" Different facets available for different data types
52
Facets
53
Example: enumeration <xs:simpleType name="grade">
<xs:restriction base="xs:string"> <xs:enumeration value="A"/> <xs:enumeration value="B"/> <xs:enumeration value="C"/> <xs:enumeration value="D"/> <xs:enumeration value="F"/> <xs:enumeration value="I"/> </xs:restriction> </xs:simpleType>
54
Example: numeric <xs:simpleType name="drinkingAge">
<xs:restriction base="xs:positiveInteger"> <xs:minInclusive value="21"/> </xs:restriction> </xs:simpleType>
55
Example: pattern Regular expressions again derived from perl
<xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="([A-D]|F|I)(\+|\-)?" /> </xs:restriction> </xs:simpleType>
56
Inheritance facet restrictions are inherited For example
new type derivations must honor them but can restrict them further but new derivations can alter other facets For example monetary type fractionDigits facet = 2 loan amount type monetary type + maxValue = car loan amount loan amount type + maxValue = 30000
57
Complex Types Possible to derive from complex types Use complexContent
i.e. elements Use complexContent Possibilities extension restriction elements attributes
58
Exercise <!ELEMENT state (#PCDATA)>
<!ATTLIST contact type ( | fax | phone | web) #REQUIRED> <!ELEMENT street (#PCDATA)>
59
Design decisions Attribute vs element Level of granularity Naming
Schema structure
60
Attribute vs element Some specific rules General principle Element
ID must be attribute General principle data vs metadata Element for document content Attribute for information about content Not always easy to tell!
61
Element Consists of document content Will be shown to a human user
Contains substructure Sequence may be important Could be very long Presence depends on other values
62
Attribute (Opposite of above) Must be from an enumeration of values
Also consistency
63
Level of granularity How detailed to model the data? Very detailed
more work to markup more detail in expressing the schema exceptions must be handled Less detailed easier to mark up easier to schematize document contents less accessible
64
Element content granularity
Fine grained model salutation, first name, middle name, last name, appellation Coarse grained model name Tradeoff search / sort / organized document creation
65
Levels vs recursion Named levels Recursion Tradeoff
<chapter> <section> <subsection> <subsubsection> Recursion Tradeoff ability to rearrange transparency of markup
66
Naming Case convention Multiple words UPPERCASE IS BAD
lowercase better Multiple words CapCase camelCase Underline_Convention
67
Structure Nested Flat Type-based "russian doll"
schema looks like the document small schema only Flat elements defined at global level references used in complex type definitions Type-based "venetian blind" all schema complex in type defintions one global element
Similar presentations
