web data management n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Web Data Management PowerPoint Presentation
Download Presentation
Web Data Management

Loading in 2 Seconds...

play fullscreen
1 / 64

Web Data Management - PowerPoint PPT Presentation


  • 112 Views
  • Uploaded on

Web Data Management. XML and its Syntax. Why XML is of Interest to Us. XML is just syntax for data Note: we have no syntax for relational data But XML is not relational: semistructured This is exciting because: Can translate any legacy data to XML Can ship XML over the Web (HTTP)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Web Data Management' - mimir


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
web data management

Web Data Management

XML and its Syntax

why xml is of interest to us
Why XML is of Interest to Us
  • XML is just syntax for data
    • Note: we have no syntax for relational data
    • But XML is not relational: semistructured
  • This is exciting because:
    • Can translate anylegacy data to XML
    • Can ship XML over the Web (HTTP)
    • Can input XML into any application
    • Thus: data sharing and exchange on the Web
xml data sharing and exchange
XML Data Sharing and Exchange

application

application

object-relational

Integrate

XML Data

WEB (HTTP)

Transform

Warehouse

application

relational data

legacy data

Specific data management tasks

from html to xml
From HTML to XML

HTML describes the presentation

slide5
HTML

<h1> Bibliography </h1>

<p> <i> Foundations of Databases </i>

Abiteboul, Hull, Vianu

<br> Addison Wesley, 1995

<p> <i> Data on the Web </i>

Abiteoul, Buneman, Suciu

<br> Morgan Kaufmann, 1999

slide6
XML

<bibliography>

<book> <title> Foundations… </title>

<author> Abiteboul </author>

<author> Hull </author>

<author> Vianu </author>

<publisher> Addison Wesley </publisher>

<year> 1995 </year>

</book>

</bibliography>

XML describes the content

relevance of xml
Relevance of XML
  • Databases are basically metadata about actual data contained in other tables
  • Actually describing & understanding the data poses a problem
  • XML binds a piece of data to what it is supposed to accomplish
  • Information is human & machine readable
  • XML is easier to understand & implement
relevance of xml1
Relevance of XML
  • An example describing directions from one location to another

<?xml version="1.0"?>

<map>

<start>

<addr1>100 West Morgan St</addr1>

<city>Raleigh</city>

<state>NC</state>

<zip>27603</zip>

</start>

<directions>

<left distance="0.11 miles">W MORGAN ST</left>

<left distance="0.11 miles">S WILMINGTON ST</left>

<left distance="0.44 miles">E EDENTON ST</left>

<right distance="0.09 miles">N WEST ST</right>

<left distance="0.02 miles">W JONES ST</left>

</directions>

<destination>

<addr1>508 W Jones St</addr1>

<city>Raleigh</city>

<state>NC</state>

<zip>27603</zip>

</destination>

</map>

working with objects
Working with Objects
  • Object-Oriented approach allows greater flexibility
  • XML has object like implementations and uses
  • ‘Schema for Object-Oriented XML’ (SOX)
  • SOX enforces a valid Uniform Resource Identifier (URI); must include the file:// portion in the <schema> element
working with objects1
Working with Objects

<?xml version = "1.0" encoding = "UTF-8"?>

<!DOCTYPE schema SYSTEM

"urn:x-commerceone:document:com:commerceone:xdk:xml:schema.dtd$1.0">

<schema uri = "file:///S:/home_computer.sox" soxlang-version = "V0.2.2">

<elementtype name = "home_computer">

<model>

<sequence>

<element type = "monitor"/>

<element type = "housing"/>

<element type = "speakers"/>

<element type = "keyboard"/>

<element type = "mouse"/>

</sequence>

</model>

</elementtype>

<elementtype name = "monitor">

<model>

<string/>

</model>

</elementtype>

working with objects2
Working with Objects

<?xml version = "1.0" encoding = "UTF-8"?>

<!DOCTYPE schema SYSTEM "urn:x-commerceone:document:com:commerceone:xdk:xml:schema.dtd$1.0">

<schema uri = "file:///S:/home_computer.sox" soxlang-version = "V0.2.2">

<join system = "file:///S:/home_computer.sox"/>

<elementtype name = "work_computer">

<extends type = "home_computer">

<append>

<sequence>

<element type = "scanner"/>

<element type = "zip_drive"/>

<element type = "printer"/>

</sequence>

</append>

</extends>

</elementtype>

<elementtype name = "scanner">

<model>

<string/>

</model>

</elementtype>

<elementtype name = "zip_drive">

<model>

<string/>

</model>

</elementtype>

<elementtype name = "printer">

<model>

<string/>

</model>

</elementtype>

</schema>

working with objects3
Working with Objects

home_computer.sox schema

work_computer.sox schema

working with objects4
Working with Objects
  • SOX-compliant parsers pull in the required parent schemas

<?xml version = "1.0" encoding = "UTF-8"?>

<?soxtype file:///S:/work_computer.sox?>

<work_computer>

<monitor>15 inch</monitor>

<housing>

<cpu>1 GHz</cpu>

<ram>256 MB</ram>

<disk_space>60 GB</disk_space>

<modem>56k</modem>

</housing>

<speakers>JBL</speakers>

<keyboard>Microsoft</keyboard>

<mouse>Microsoft</mouse>

<scanner>Microtek</scanner>

<zip_drive>100 MB</zip_drive>

<printer>HP</printer>

</work_computer>

application messaging
Application Messaging
  • XML & SOAP enabled ‘application messaging’
  • XML used to describe the API to a Web Service
  • Software applications should be able to communicate in a near automated fashion
  • XML describes the Web Services themselves
  • Applications can query other applications to judge capability before making a request
application messaging1
Application Messaging
  • NFQuery.dtd

<?xml version='1.0' encoding='UTF-8' ?>

<!ELEMENT query (news)>

<!ELEMENT news EMPTY>

<!ATTLIST news date CDATA #REQUIRED

type (global | local | financial |

sports | travel | weather ) #REQUIRED

what (count | headers | all ) #REQUIRED

limit CDATA #IMPLIED >

  • Joe_query.xml

<?xml version = "1.0" encoding = "UTF-8"?>

<!DOCTYPE query SYSTEM "NFQuery.dtd">

<query>

<news date = "2001-10-10" type = "sports" what = "count"/>

</query>

application messaging2
Application Messaging
  • NFResponse.dtd

<?xml version='1.0' encoding='UTF-8' ?>

<!ELEMENT results (count | headers | all)>

<!ATTLIST results date CDATA #REQUIRED

type (global | local | financial |

sports | travel | weather ) #REQUIRED >

<!ELEMENT count (#PCDATA)>

<!ELEMENT headers (#PCDATA)>

<!ELEMENT all (headline+)>

<!ELEMENT headline (#PCDATA)>

  • Joe_query_response.xml

<?xml version = "1.0" encoding = "UTF-8"?>

<!DOCTYPE results SYSTEM "NFResponse.dtd">

<results date = "2001-10-10" type = "sports">

<count>53</count>

</results>

application messaging3
Application Messaging
  • Joe_get_query.xml

<?xml version = "1.0" encoding = "UTF-8"?>

<!DOCTYPE query SYSTEM "NFQuery.dtd">

<query>

<news date="2001-10-10"

type="sports" what="all" limit="10"/>

</query>

process modeling
Process Modeling
  • XML used to model process & workflow

<map>

<start>

<addr1>100 West Morgan St</addr1>

<city>Raleigh</city>

<state>NC</state>

<zip>27603</zip>

</start>

<directions>

<left distance="0.11 miles">W MORGAN ST</left>

<left distance="0.11 miles">S WILMINGTON ST</left>

<left distance="0.44 miles">E EDENTON ST</left>

<right distance="0.09 miles">N WEST ST</right>

<left distance="0.02 miles">W JONES ST</left>

</directions>

<destination>

<addr1>508 W Jones St</addr1>

<city>Raleigh</city>

<state>NC</state>

<zip>27603</zip>

</destination>

</map>

the net framework
The .NET Framework
  • Shift from individual Web sites or devices to an integrated cluster of devices & services
  • People will control what, when, and how information is delivered to them
  • HTML based presentation is augmented by XML-based information
  • XML-based .NET programming model forges the idea of XML-based Web Services
  • Web services use protocols like HTTP & XML
xml within net
XML within .NET
  • XML obvious choice to represent commands and typed data
  • XML standard metalanguage for describing data
  • SOAP is an industry standard for using XML
  • Service Contract Language (SCL); XML grammar for documenting Web Service contracts
  • Businesses can create a variety of value-added applications by combining Web Services
required knowledge
Required Knowledge
  • XML is simply metadata used to describe

a markup language

  • Knowledge of XPath or SOAP is helpful
  • You may use a text editor or some IDE
  • You can even write your own parser for validating instance documents
  • Refer to help resources on the web:
    • http://www.w3.org
    • http://www.ietf.org
    • http://www.oasis-open.org
goals of xml
Goals of XML
  • The goals behind creating the XML language:
    • should be compatible with SGML
    • should support a variety of applications
    • should be easily usable over the internet
    • xml design should be prepared quickly
    • design of XML shall be formal and concise
    • xml documents should be reasonably clear
    • xml documents should be uncomplicated to create
    • programs processing XML documents easy to write
    • terseness in XML markup is of minimal importance
    • optional features should be kept to a bare minimum
the xml language
The XML Language
  • Elements: represent tags or language that you create with XML

<!ELEMENT nametype>

  • A customer data model..
the xml language1
The XML Language
  • We first define our customer element

<!ELEMENT customer (name , contact)>

  • You can impose some rules on this, such as having name OR contact
  • Defining <name> and <contact> is similar as they are parents of child elements:
    • <!ELEMENT name (first , middle , last)>
    • <!ELEMENT contact (address , phone)>
    • <!ELEMENT address (street , city , state , zip)>
    • <!ELEMENT phone (home , work , mobile)>
xml terminology
XML Terminology
  • tags: book, title, author, …
  • start tag: <book>, end tag: </book>
  • elements: <book>…<book>,<author>…</author>
  • elements are nested
  • empty element: <red></red> abbrv. <red/>
  • an XML document: single root element
xml syntax
XML Syntax
  • Another example:

<

db

>

<

book

>

<

title

>

Complete Guide to DB2

</

title

>

<

author

>

Chamberlin

</

author

>

</

book

>

<

book

>

<

title

>

Transaction Processing

</

title

>

<

author

>

Bernstein

</

author

>

<

author

>

Newcomer

</

author

>

</

book

>

<

publisher

>

<

name

>

Morgan Kaufman

</

name

>

<

state

>

CA

</

state

>

</

publisher

>

</

db

>

the xml tree
The XML Tree

db

book

book

publisher

title

author

author

name

state

title

author

“Complete

Guide

to DB2”

“Morgan

Kaufman”

“CA”

“Chamberlin”

“Transaction

Processing”

“Bernstein”

“Newcomer”

Tags on nodes

Data values on leaves

xml components
XML Components
  • An XML file normally consists of three types of markup, the first two of which are optional:

1.An XML processing instruction(PI) identifying the version of XML being used, the way in which it is encoded, and whether it references other files or not, e,g,

<?xml version="1.0" encoding="UCS2" standalone="yes">

xml components1
XML Components

2.A document type declaration(DTD)

  • either contains the formal markup declarations in its internal subset (between square brackets) or
  • references a file containing the relevant markup declarations (the external subset), e.g.:

<!DOCTYPE memo SYSTEM "http://www.myco.com/dtds/memo.dtd">

xml components2
XML Components

3.A fully-tagged document instancewhich

  • consists of a root element, whose
  • element type name must match that assigned as the document type name in the document type declaration, within which all other markup is nested.
xml characteristics
XML Characteristics
  • Validity
    • If all three components are present, and
    • the document instance conforms to the rules defined in the document type definition
  • Well-formed
    • if each element is properly nested within its parent elements,
    • if it has matching tags
    • if each attribute is specified as an attribute name followed by a value indicator (=) and a quoted string.
xml components3
XML Components
  • Six kinds of markup that can occur in an XML document: elements, entityreferences, comments, processinginstructions, marked sections, anddocument type declarations.
  • Document Type Declarations
    • An XML document primarily consists of a strictly nested hierarchy of elements with a single root.
    • Elements can contain character data, child elements, or a mixture of both. In addition, they can have attributes.
xml components4
XML Components
  • Child character data and child elements are strictly ordered; attributes are not. For example:
  • <?xml version="1.0" ?>
  • <Book Author="Anonymous">
  • <Title>Sample Book</Title>
  • <Chapter id="1">
  • This is chapter 1. It is not very long or interesting.
  • </Chapter>
  • <Chapter id="2">
  • This is chapter 2. Although it is longer than chapter 1,
  • it is not any more interesting.
  • </Chapter>
  • <comments/>
  • </Book>
types or schemas for xml
“Types” (or “Schemas”) for XML
  • Document Type Definition – DTD
  • Define a grammar for the XML document
    • we use it as substitute for types/schemas
  • Will be replaced by XML-Schema
document type definition dtd
Document Type Definition (DTD)
  • The Document Type Definition(DTD) is either
    • contained in a <!DOCTYPE> tag, contained in an external file and referenced from a <!DOCTYPE> tag, or both.
  • PCDATA means Parsed Character Data (a mouthful for string)

<!DOCTYPE Book [

<!ELEMENT Book (Title, Chapter+,comments?)>

<!ATTLIST Book Author CDATA #REQUIRED>

<!ELEMENT Title (#PCDATA)>

<!ELEMENT Chapter (#PCDATA)>

<!ATTLIST Chapter id ID #REQUIRED>

<!ELEMENT comments EMPTY>

]>

an example dtd
An Example DTD

<!DOCTYPE db [

<!ELEMENT db ((book|publisher)*)>

<!ELEMENT book (title,author*,year?)>

<!ELEMENT title (#PCDATA)>

<!ELEMENT author (#PCDATA)>

<!ELEMENT year (#PCDATA)>

<!ELEMENT publisher (#PCDATA)>

]>

  • PCDATA means Parsed Character Data(a mouthful for string)
dtds as grammars
DTDs as Grammars

db ::= (book|publisher)*

book ::= (title,author*,year?)

title ::= string

author ::= string

year ::= string

publisher ::= string

  • A DTD is a EBNF (Extended BNF) grammar
  • An XML tree is precisely a derivation tree

XML Documents that have a DTD and conform to it are called valid

dtd vs xml schema
DTD Vs XML Schema
  • DTD: old style typing, still very used
  • XML schema: more modern, used e.g. in Web services
  • DTD:

<!ELEMENT note (to, from, heading, body)>

<!ELEMENT to (#PCDATA)>

<!ELEMENT from (#PCDATA)>

<!ELEMENT heading (#PCDATA)>

<!ELEMENT body (#PCDATA)>

dtd vs xml schema1
DTD Vs XML Schema
  • The same structure in XML schema (an XML dialect)

<?xml version="1.0"?>

<xs:schemaxmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="note">

<xs:complexType>

<xs:sequence>

<xs:element name="to" type="xs:string“ minOccurs=’1’ maxOccurs=’1’/>

<xs:element name="from" type="xs:string"/>

<xs:element name="heading" type="xs:string"/>

<xs:element name="body" type="xs:string"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

elements
Elements

1) An element is defined as a group of one or more subelements/subgroups, character data, EMPTY, or ANY. For example:

  • Group:
    • <!ELEMENT A (B, C)>
  • Character data:
    • <!ELEMENT A (#PCDATA)>
  • Empty:
    • <!ELEMENT A EMPTY>
  • Any:
    • <!ELEMENT A ANY>>
elements1
Elements

2) Elements defined as groups of subelements/ subgroups constitute non-terminals in the language. Elements defined as character data, EMPTY, or ANY constitute terminals. For example:

  • It is legal to define a language containing non-terminals that never resolve to terminals, such as one with purely circular definitions
  • It is generally impossible and/or useless to create any valid documents for such languages.
  • <!-- Element A is a non-terminal. -->
  • <!ELEMENT A (B)>
  • <!-- Element B is a terminal. -->
  • <!ELEMENT B (#PCDATA)>
elements2
Elements

3) Groups can be either a sequence or choice of subelements and/or subgroups. For example:

  • Sequence:
    • <!-- Element A consists of a single element B. -->
    • <!ELEMENT A (B)>
    • <!-- Element A consists of element B followed by element C. -->
    • <!ELEMENT A (B, C)>
    • <!-- Element A consists of a sequence, including a choice subgroup. -->
    • <!ELEMENT A (B, (C | D), E)>
  • Choice:
    • <!-- Element A consists of either element B or element C. -->
    • <!ELEMENT A (B | C)>
    • <!-- Element A consists of a choice, including a sequence subgroup. -->
    • <!ELEMENT A (B | C | (D, E))>
elements3
Elements

4) Optional (?), one-or-more (+), and zero-or-more (*) operators can be applied to groups, subgroups, and subelements. For example:

  • Optional:
    • <!-- Subelement B is optional. -->
    • <!ELEMENT A (B?, C)>
  • One or more:
    • <!-- Subgroup (C | D) occurs one or more times. -->
    • <!ELEMENT A (B, (C | D)+, E)>
  • Zero or more:
    • <!-- Group (B, C) occurs zero or more times, i.e. A can be empty. -->
    • <!ELEMENT A (B, C)*>
elements4
Elements

5) Elements containing character data can be declared as containing only character data:

  • The latter case is an example of “mixed content”
  • "PCDATA" in the declarations is short for "Parsed Character DATA".
    • <!ELEMENT A (#PCDATA)>
  • or as containing a mixture of character data and elements:
      • <!ELEMENT A (#PCDATA | B | C)*>
elements5
Elements

6) EMPTY means that the element has no child elements or character data.

7) ANY means that the element can contain zero or more child elements of any declared type, as well as character data.

  • It is therefore a shorthand for mixed content containing all declared elements.
attributes
Attributes

1) Elements can have zero or more attributes. For example:

  • Attributes are name-value pairs that occur inside tags after the element name.
  • In XML, all attribute values must be quoted.
  • Attributes are alternative ways to represent data
  • <!ELEMENT A (#PCDATA)>
  • <!-- Declare an attribute a for element A -->
  • <!ATTLIST A a CDATA #IMPLIED>

<div class="preface">

attributes1
Attributes

<bookprice = “55” currency = “USD”>

<title> Complete Guide to DB2 </title>

<author> Chamberlin </author>

<year> 1998 </year>

</book>

price, currency are called attributes

replacing attributes with elements
Replacing Attributes with Elements

<book>

<title> Complete Guide to DB2 </title>

<author> Chamberlin </author>

<year> 1998 </year>

<price> 55 </price>

<currency> USD </currency>

</book>

attributes are alternative ways to represent data

attributes2
Attributes

2) A single ATTLIST statement can declare multiple attributes for the same element. Multiple ATTLIST statements can declare attributes for the same element. That is, the following are equivalent:

  • Single ATTLIST statement declaring multiple attributes for an element:
      • <!-- Element A has attributes a and b -->
      • <!ATTLIST A
      • a CDATA #IMPLIED
      • b CDATA #IMPLIED>
  • Multiple ATTLIST statements declaring attributes for the same element:
      • <!-- Element A has attributes a and b -->
      • <!ATTLIST A a CDATA #IMPLIED>
      • <!ATTLIST A b CDATA #IMPLIED>
attributes3
Attributes

3) Attributes can be optional, required, or have a fixed value. Optional attributes can have a default; fixed attributes must have a default. For example:

  • Optional without a default:
    • <!-- Element A has an attribute a. #IMPLIED = "optional, no default" -->
    • <!ATTLIST A a CDATA #IMPLIED>
  • Optional with a default:
    • <!-- If attribute a is not provided, a default of "aaa" will be used. -->
    • <!ATTLIST A a CDATA "aaa">
  • Required:
    • <!ATTLIST A a CDATA #REQUIRED>
  • Fixed:
    • <!-- The value of attribute a is always "aaa" -->
    • <!ATTLIST A a CDATA #FIXED "aaa">
attributes4
Attributes

4) Each attribute has a type:

  • Character data:
  • A user-defined enumerated type
  • <!ATTLIST A a CDATA #IMPLIED>

<!-- Attribute a uses a simple enumeration. -->

<!ATTLIST A a (yes | no) #IMPLIED>

<!-- Attribute a uses an enumeration of notation types.-->

<!ATTLIST A a NOTATION (ps | pdf) #IMPLIED>

attributes5
Attributes
  • ID, IDREF: These attributes point from one element to another. The value of the IDREF attribute on the pointing element is the same as the value of the ID attribute on the pointed-to element.
  • <!-- Attribute id gives the ID of element A -->
  • <!ATTLIST A id ID #IMPLIED>
  • <!-- Attribute ref points to the ID of another element -->
  • <!ATTLIST A ref IDREF #IMPLIED>
oids and references
Oids and References

<personid=“o555”> <name> Jane </name> </person>

<personid=“o456”> <name> Mary </name>

<childrenidref=“o123 o555”/>

</person>

<personid=“o123” mother=“o456”><name>John</name>

</person>

oids and references in XML are just syntax

attributes6
Attributes
  • ENTITY, ENTITIES. These attributes point to external data in the form of unparsed entities.
  • NMTOKEN, NMTOKENS. These attributes have single/multiple tokens as values.
  • <!-- Attribute a points to a single unparsed entity -->
  • <!ATTLIST A a ENTITY #IMPLIED>
  • <!-- Attribute b points to multiple unparsed entities -->
  • <!ATTLIST A b ENTITIES #IMPLIED>
  • <!ATTLIST A a NMTOKEN #IMPLIED>
  • <!ATTLIST A b NMTOKENS #IMPLIED>
entity declarations
Entity Declarations
  • Entity declarations allow you to associate a name with some other fragment of the document.
  • That construct can be a chunk of regular text, a chunk of the document type declaration, or a reference to an external file containing either text or binary data.

<!ENTITY ATI "ArborText, Inc.">

<!ENTITY boilerplate SYSTEM "/standard/legalnotice.xml">

<!ENTITY ATIlogo SYSTEM "/standard/logo.gif" NDATA GIF87A>

entity declarations1
Entity Declarations
  • There are three kinds of entities: Internal, external, and parametric.
  • Internal Entities
    • the replacement text is stored in the declaration.
    • Using &ATI; anywhere in the document insert “ArborText, Inc.” at that location.
    • character reference, can be used to insert arbitrary Unicode characters
    • Character references take one of two forms: decimal references, &#8478; , and
    • hexadecimal references, &#x211E; . Both of these refer to character number U+211E from Unicode
entity declarations2
Entity Declarations
  • Internal entities can include references to other internal entities, but it is an error for them to be recursive.
  • Example: <element> this is less than &lt; </element>
  • The XML specification predefines five internal entities:
entity declarations3
Entity Declarations
  • External Entities
    • Using &boilerplate; will insert the contents of the file /standard/legalnotice.xml
    • The XML processor will parse the content of that file as if its content had been typed at the location of the entity reference.
    • The entity ATIlogo is also an external entity, but its content is binary.
    • The ATIlogoentity can only be used as the value of an ENTITY (or ENTITIES) attribute (on a graphic element, perhaps).
entity declarations4
Entity Declarations
  • Parameter Entities
    • Parameter entities can only occur in the document type declaration.
    • A parameter entity is identified by placing “% ” (percent-space) in front of its name in the declaration.
    • The percent sign is also used in references to parameter entities, instead of the ampersand.
    • Parameter entity references are immediately expanded in the document type declaration and their replacement text is part of the declaration, whereas normal entity references are not expanded.
notation declarations
Notation Declarations
  • specific types of external binary data.
  • This information is passed to the processing application, which may make whatever use of it that it wishes. A typical notation declaration is:
  • Comments

<!NOTATION GIF87A SYSTEM "GIF">

  • <!-- and end with -->
processing instructions
Processing Instructions
  • Processing instructions (PIs) are an escape hatch to provide information to an application.
  • XML processor is required to pass them to an application.
  • Syntax: <?target argument?>
  • Example:<product> <name> Alarm Clock </name><?ringBell 20?> <price> 19.99 </price></product>
  • The names used in PIs may be declared as notations in order to formally identify them.
cdata sections
CDATA Sections
  • In a document, a CDATA section instructs the parser to ignore most markup characters.
  • Consider a source code listing in an XML document.
  • It might contain characters that the XML parser would ordinarily recognize as markup (< and &, for example).
  • comments are not recognized in a CDATA section.
  • <![CDATA[
  • *p = &q;
  • b = (i <= 3);
  • ]]>
xml namespaces
XML Namespaces
  • http://www.w3.org/TR/REC-xml-names (1/99)
  • A particular label, e.g., number, may denote different notions in different contexts
  • name ::= [prefix:]localpart

<bookxmlns:isbn=“www.isbn-org.org/def”>

<title> … </title>

<number> 15 </number>

<isbn:number> …. </isbn:number>

</book>

xml namespaces1

defined here

XML Namespaces
  • syntactic: <number> , <isbn:number>
  • semantic: provide URL for schema

<tagxmlns:mystyle= “http://…”>

<mystyle:title> … </mystyle:title>

<mystyle:number> …

</tag>