EMERGING TECHNOLOGIES. XML Documents and Schemas for XML documents

Size: px

Start display at page:

Download "EMERGING TECHNOLOGIES. XML Documents and Schemas for XML documents"

Calvin Lane
5 years ago
Views:

1 EMERGING TECHNOLOGIES XML Documents and Schemas for XML documents

2 Outline 1. Introduction 2. Structure of XML data 3. XML Document Schema 3.1. Document Type Definition (DTD) 3.2. XMLSchema 4. Data Model for XML documents. 5. XML Query Languages 5.1. XPath 5.2. XQuery

3 1. Introduction (1) XML: Extensible Markup Language. Defined by the WWW Consortium (W3C). Originally intended as a document markup language not a database language. - Documents have tags giving extra information about sections of the document. E.g. <title> XML </title> <slide> Introduction </slide> Derived from SGML (Standard Generalized Markup Language), but simpler to use than SGML.

4 1. Introduction (2) Unlike SGML and HTML, XML can represent database data and other kinds of data used in database applications. Unlike HTML, XML is extensible: Users can add new tags, and separately specify how the tag should be handled for display. The ability to specify new tags, and to create nested tag structures made XML a great way to exchange data, not just documents.

5 1. Introduction (3): From HTML to XML For the family of markup languages that include HTML, SGML, and XML the markup takes the form of tags enclosed into angle brackets, <>. Tags are used in pairs of the form <tag>, </tag>. e.g. <title> Databases </tile> With HTML, various pieces of text in a document are marked with tags that affect the rendering of that text by a web browser. e.g. Text between <table> and </table> will be rendered by the browser as a table. The tag <p> is supposed to tell the browser to start a new paragraph. The number of tags in HTML is fixed by the HTML definition. The browser displays an HTML document by implementing the semantics of each tag.

6 1. Introduction (4): From HTML to XML In contrast, the repertoire of tags in XML is not set in advance. Further, there is no fixed semantics for any XML tag. With XML, markup languages evolved from specifying instructions on how to print parts of a document, to specifying the function of a document. E.g. <title> Databases </tile> can represent a section heading instead of text to be printed in large size, bold face. XML is particularly useful as a data format when an application must communicate with another application, or when it must integrate information from several other applications.

7 2. Structure of XML Data (1): Syntax Tag: label for a section of data. Element: section of data beginning with <tagname> and ending with matching </tagname>. tagname is the name of the element. Elements must be properly nested. Proper nesting: <account> <balance>.</balance> </account> Improper nesting: <account> <balance>.</account> </balance> Formally: every start tag must have a unique matching end tag, that is in the context of the same parent element. Elements directly nested within one element are called subelements or children. Every document must have a single top-level element (root element).

8 2. Structure of XML Data (2): Nested Elements Example: <bank-1> <customer> <customer-name> Hayes </customer-name> <customer-street> Main </customer-street> <customer-city> Harrison </customer-city> <account> <account-number> A-102 </account-number> <branch-name> Perryridge </branch-name> <balance> 400 </balance> </account> </customer> <customer> </customer> </bank-1>

9 2. Structure of XML Data (3): Motivation for Nesting Nesting of data is useful in data transfer. Example: elements representing customer-id, customer name, and address nested within an order element. Nested representations are widely used in XML data interchange applications to avoid joins. Nesting is not supported, or discouraged, in relational databases. -With multiple orders, customer name and address are stored redundantly. -Normalization replaces nested structures in each order by foreign keys into table storing customer name and address information. -Nesting is supported in object-relational databases. But nesting is appropriate when transferring data. -External application does not have direct access to data referenced by a foreign key

10 2. Structure of XML Data (4): Syntax Mixture of text with sub-elements is legal in XML. Example: <account> This account is seldom used any more. <account-number> A-102</account-number> <branch-name> Perryridge</branch-name> <balance>400 </balance> </account> This feature makes more sense in a document processing context, but is not particularly useful for representing more structured data (e.g. a database content) in XML. The text between the opening and the closing tag of an element is called the content of that element.

11 2. Structure of XML Data (5): Attributes Elements can have attributes. Example: <account acct-type = checking > <account-number> A-102 </account-number> <branch-name> Perryridge </branch-name> <balance> 400 </balance> </account> Attributes are specified by name=value pairs inside the starting tag of an element. An element may have several attributes, but each attribute name can only occur once. E.g.: <account acct-type = checking monthly-fee= 5 >

12 2. Structure of XML (6): Attributes vs. Subelements Distinction between subelement and attribute: -In the context of documents, attributes are part of markup, while subelement contents are part of the basic document contents. -In the context of data representation, the difference is unclear and may be confusing. Same information can be represented in two ways. E.g.: <account account-number = A-101 >. </account> <account> <account-number>a-101</account-number> </account> Suggestion: use attributes for identifiers of elements (to be discussed later), and use subelements for contents.

13 2. Structure of XML (7): More on XML Syntax Elements without subelements or text content can be abbreviated by ending the start tag with a /> and deleting the end tag. Such elements are called empty elements. E.g.: <account number= A-101 branch= Perryridge balance= 200 /> To store string data that may contain tags, without the tags being interpreted as subelements, use CDATA as below. E.g.: <![CDATA[<account> </account>]]> Here, <account> and </account> are treated as just strings.

14 2. Structure of XML (8): More on XML Syntax Apart from elements and attributes XML allows also processing instructions. A processing instruction can contain pretty much anything the document author wants to communicate to the XML processor (in the hope that the procesor knows what to do with this information). A processing instruction is a statement of the from: <? my-command bring some coffee?> Processing instructions are used fairly rarely. XML allows also comments which take the following form: <!- A comment -> It is allowed to occur everywhere instead inside the markups.

15 2. Structure of XML Data (9): Namespaces XML data has to be exchanged between organizations. Same tag name may have different meaning in different organizations, causing confusion on exchanged (or integrated) documents. For instance, the term Name might have different meaning and structure depending on whether we talk about people or companies: <Name> <First>John</First> <Last>Doe</Last> </Name> <Name> IBM </Name> Specifying a unique string as an element name avoids confusion.

16 2. Structure of XML Data (10): Namespaces Better solution: use namespace:element-name. The idea of a namespace is to prepend each tag or attribute by a uniform resource identifier (URI) which can be an abstract identifier (a general string of characters serving as a unique identifier) or a Uniform Resource Locator (URL) -- a Web page address. The abstract identifier avoids the use of unique names all over document.

17 2. Structure of XML Data (11): Namespaces Example: The following element bank has an attribute xmlns:fb, which declares that FB is defined as an abbreviation for the URL <bank xmlns:fb= > The abbreviation can then be used in various element tags within the document rooted at element bank: <FB:branch> <FB:branchname>Downtown</FB:branchname> <FB:branchcity>Brooklyn</FB:branchcity> </FB:branch> </bank>

18 2. Structure of XML Data (12): Namespaces One can declare several namespaces as long as their identifiers are distinct. Different subelements can then be associated with different namespaces. A default namespace can be defined, by using attribute xmlns instead of xmlns:fb in the root element of the document: <bank xmlns= xmlns:fb= > Attributes without an explicit namespace prefix would then belong to the default namespace. Namespace declarations have scope which can be nested like a program block.

19 2. Structure of XML (13): XML declaration The first line of an XML document is an XML declaration that is, a processing instruction that tells the XML processor that is dealing with some version of XML (other attributes might also be included there). E.g. <?xml version= 1.0?>

20 2. Structure of XML Data (14): Well Formed XML documents We can now define an important correctness requirement. An XML document is well formed if the following conditions hold: -It starts with an XML declaration to indicate the version of XML that is being used as well as any other relevant attributes. -It has a root element. -Every opening tag is followed by a matching closing tag, and the elements are properly nested inside each other. -An attribute can occur at most once in a given opening tag; its value must be provided; and its value must be quoted.

21 3. XML Document Schema Databases have schemas which are used to constraint what information can be stored in the database and to constraint the data types of the stored information. In contrast, by default, XML documents can be created without any associated schema: An element may have any subelement or attribute. While such freedom may occasionally be acceptable given the selfdescribing nature of the data format, it is not generally useful when: - XML documents must be processed automatically as part of an application, or - Large amounts of related data are to be formatted in XML. The document Type Definition (DTD) and the more recent XMLSchema are two document oriented schema mechanisms of the XML standard.

22 3.1 Document Type Definition (1): Introduction The Document Type Definition (DTD) is an optional part of an XML document. The main purpose of a DTD is much like that of a schema: to constraint the type of data present in the document. However, a DTD does not in fact constraint types in the sense of basic types like integers and strings. Instead, it only constraints the appearance of subelements and attributes within an element. The DTD is primarily a list of rules for what pattern of subelements appear within a document.

23 3.1 Document Type Definition (2): Syntax DTD constraints the structure of XML data. - What elements can occur. - What attributes can/must an element have. - What subelements can/must occur inside each element, and how many times. All values represented as strings in XML DTD syntax - <!ELEMENT element(subelements-specification)> - <!ATTLIST element (attributes) >

24 3.1 DTDs (3): Element Specification Subelements can be specified as: - names of elements, or - #PCDATA (parsed character data), i.e., character strings, or - EMPTY (no subelements) or ANY (anything can be a subelement) Example <!ELEMENT depositor (customer-name, account-number)> <!ELEMENT customer-name (#PCDATA)> <!ELEMENT account-number (#PCDATA)> Subelement specification may have regular expressions. E.g.: <!ELEMENT bank (( account customer depositor)+)> Notation: - alternatives (or) or more occurrences * - 0 or more occurrences? - 0 or 1 occurrence (optional element)

25 3.1 Document Type Definition (4): Example Example <!DOCTYPE bank [ <!ELEMENT bank ( ( account customer depositor)+)> <!ELEMENT account (account-number, branch-name, balance)> <!ELEMENT customer(customer-name, customer-street, customer-city)> <!ELEMENT depositor (customer-name, account-number)> <!ELEMENT account-number (#PCDATA)> <!ELEMENT branch-name (#PCDATA)> <!ELEMENT balance(#pcdata)> <!ELEMENT customer-name(#pcdata)> <!ELEMENT customer-street(#pcdata)> <!ELEMENT customer-city(#pcdata)> ]>

26 3.1 DTDs (5): Attribute Specification Attribute specification : for each attribute - Name - Type of attribute CDATA ID (identifier) or IDREF (ID reference) or IDREFS (multiple IDREFs) -- more on this later - Whether mandatory (#REQUIRED) has a default value (value), or neither (#IMPLIED) Examples <!ATTLIST account acct-type CDATA checking > <!ATTLIST customer customer-id ID #REQUIRED accounts IDREFS #REQUIRED >

27 3.1 DTDs (6): IDs and IDREFs An element can have at most one attribute of type ID. The ID attribute value of each element in an XML document must be distinct. - Thus the ID attribute value is an object identifier. An attribute of type IDREF must contain the ID value of an element in the same document. (Thus IDREF is a poor cousin of a foreign key) An attribute of type IDREFS contains a set of (0 or more) ID values. Each ID value must be the ID value of an element in the same document

28 3.1 Document Type Definition (7): Example Bank DTD with ID and IDREF attribute types. <!DOCTYPE bank-2[ <!ELEMENT bank-2 (account*, customer*)> <!ELEMENT account (branch-name, balance)> <!ATTLIST account account-number ID #REQUIRED owners IDREFS #REQUIRED> <!ELEMENT customer(customer-name, customer-street, customer-city)> <!ATTLIST customer customer-id ID #REQUIRED accounts IDREFS #REQUIRED> declarations for branch-name, balance, customer-name, customer-street and customer-city ]>

29 3.1 Document Type Definition (8): Example XML data with ID and IDREF attributes. <bank-2> <account account-number= A-401 owners= C100 C102 > <branch-name> Downtown </branch-name> <balance> 500 </balance> </account> <customer customer-id= C100 accounts= A-401 > <customer-name> Joe </customer-name> <customer-street> Monroe </customer-street> <customer-city> Madison </customer-city> </customer> <customer customer-id= C102 accounts= A-401 A-402 > <customer-name> Mary </customer-name> <customer-street> Erin </customer-street> <customer-city> Newark </customer-city> </customer> </bank-2>

30 3.1 DTDs (9): Valid XML Document A document that conforms to its DTD it said to be valid. The XML specification does not require processors to check each document for conformance to its DTD, because some applications might not care if the document is valid. XML does not even require that a document has a DTD but it does require that a document is well formed.

31 3.1 DTDs (10): Conformance Checking To require that an XML document is checked for conformance to a DTD we must specify this in the declaration of a document. E.g. the first line of our XML document can be changed to <?xml version= 1.0 standalone= no?> When the value of standalone is no the document needs to be checked against a separate DTD document.

32 3.1 DTDs (11): DTD file declaration The DTD document text can be included at the beginning of the XML document to allow the checking. Alternatively, the declaration of the XML document could be: <?xml version= 1.0 standalone= no?> <!DOCTYPE bank-2 SYSTEM = bank-2.dtd > Then, the DTD file should be stored in the same file system as the XML document and should be given the file name bank-2.dtd. Alternatively the XML document can give a URL where its DTD can be found.

33 3.1 DTDs (12): A Bigger Example Example The first part of an XML document

34 3.1 DTDs (13): A Bigger Example Example (cont.) The second part of the XML document

35 3.1 DTDs (14): A Bigger Example Example (cont.) A DTD for the previous XML document.

36 3.1 DTDs (15): Limitations of DTDs No typing of text elements and attributes. - All values are strings, no integers, reals, etc. Difficult to specify unordered sets of subelements. - Order is usually irrelevant in databases. - (A B)* allows specification of an unordered set, but Cannot ensure that each of A and B occurs only once. IDs and IDREFs are untyped. - The owners attribute of an account may contain a reference to another account, which is meaningless. owners attribute should ideally be constrained to refer to customer elements

37 3.2 XMLSchema (1): Features XML Schema is a more sophisticated schema language which addresses the drawbacks of DTDs. Supports: - Typing of values. E.g. integer, string, etc. Also, constraints on min/max values. - User defined types. - Is itself specified in XML syntax, unlike DTDs. More standard representation, but verbose. - Is integrated with namespaces. - Many more features. List types, uniqueness and foreign key constraints, inheritance BUT: significantly more complicated than DTDs, not yet widely used.

38 3.2 XMLSchema (2): Example <xsd:schema xmlns:xsd= <xsd:element name= bank type= BankType /> <xsd:element name= account > <xsd:complextype> <xsd:sequence> <xsd:element name= account-number type= xsd:string /> <xsd:element name= branch-name type= xsd:string /> <xsd:element name= balance type= xsd:decimal /> </xsd:squence> </xsd:complextype> </xsd:element>... definitions of customer and depositor <xsd:complextype name= BankType > <xsd:sequence> <xsd:element ref= account minoccurs= 0 maxoccurs= unbounded /> <xsd:element ref= customer minoccurs= 0 maxoccurs= unbounded /> <xsd:element ref= depositor minoccurs= 0 maxoccurs= unbounded /> </xsd:sequence> </xsd:complextype> </xsd:schema>

Introduction. " Documents have tags giving extra information about sections of the document

Introduction. Documents have tags giving extra information about sections of the document Chapter 10: XML Introduction! XML: Extensible Markup Language! Defined by the WWW Consortium (W3C)! Originally intended as a document markup language not a database language " Documents have tags giving