SOA - WS-Topic 3-I

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 33

SERVICE ORIENTED ARCHITECTURE

& WEB SERVICES


ITC 3013

Dr.Chamara
Dept. of ICT, Faculty of Technology
University of Sri Jayewardenepura

SOA DATA MODEL TOPIC 3-1


WELL-FORMEDNESS & VALIDITY
An XML document with correct syntax is called “Well
Formed”.
 XML documents must have a root element
 XML elements must have a closing tag
 XML tags are case sensitive
 XML elements must be properly nested
 XML attribute values must be quoted

A “Valid” XML document must also conform to a specified


document type.
VALID XML DOCUMENTS
A valid XML document is not the same as a well formed
XML document.
 The first rule, for a valid XML document, is that it must be well
formed.
 The second rule is that a valid XML document must conform to a
document type.
 Rules that defines legal elements and attributes for XML documents
are often called document definitions, or document schemas.
DOCUMENT DEFINITIONS
There are different types of document definitions that can
be used with XML.
 The original - Document Type Definition (DTD)
 The newer, and XML based - XML Schema (XSD - XML Schema
Type Definition)

An XML document validated against a document definition


is both "Well Formed" and "Valid".
DOCUMENT TYPE DEFINITION (DTD)
A Document Type Definition (DTD) defines the
legal building blocks of an XML document. It defines the
document structure with a list of legal elements and
attributes.
A DTD can be declared inline inside an XML document, or
as an external reference.
 Internal DTD – It can directly include markup declarations in the
document that form the internal DTD.
 External DTD – It can reference external markup declarations that
form the external DTD.
INTERNAL DTD DECLARATION
If the DTD is declared inside the XML file, it should be
wrapped in a DOCTYPE definition with the following
syntax:

Usage
With a DTD, independent groups of people can agree on
a standard DTD for interchanging data.
An application can use a DTD to verify that XML data is
valid.
INTERNAL DTD DECLARATION: EXAMPLE
INTERNAL DTD DECLARATION: EXAMPLE
The DTD in the example can be explained like this:
 !DOCTYPE address defines that the root element of this document is
address.
 !ELEMENT address defines that the address element contains five
elements: name, no, street, city and country
 !ELEMENT name defines the name element to be of type #PCDATA
 !ELEMENT no defines the no element to be of type #PCDATA
 !ELEMENT street defines the street element to be of type #PCDATA
 !ELEMENT city defines the city element to be of type #PCDATA
 !ELEMENT country defines the country element to be of type
#PCDATA
EXTERNAL DTD DECLARATION
If the DTD is declared in an external file, it should be
wrapped in a DOCTYPE definition with the following
syntax:
EXTERNAL DTD DECLARATION: EXAMPLE
This is the same XML document as before, but with an
external DTD.
EXTERNAL DTD DECLARATION: EXAMPLE
The file “address.dtd” contains the following DTD:
DECLARING ELEMENTS
In a DTD, elements are declared with an element
declaration with the following syntax:

or
EMPTY ELEMENTS
Empty elements are declared with the category keyword
EMPTY.

Example:

XML example:
ELEMENTS WITH PARSED CHARACTER
DATA
Elements with only parsed character data are declared
with #PCDATA inside parentheses.

Example:
PCDATA VS CDATA
PCDATA
 PCDATA means parsed character data.
 Think of character data as the text found between the start tag and
the end tag of an XML element.
 PCDATA is text that WILL be parsed by a parser. The text will be
examined by the parser for entities and markup.

CDATA
 Character Data
 All text in an XML document will be parsed by the parser, but
CDATA text will be ignored by the parser. Tags inside the text will
NOT be treated as markup.
ELEMENTS WITH ANY CONTENTS
Elements declared with the category keyword ANY, can
contain any combination of parsable data.

Example:
ELEMENTS WITH CHILDREN
Elements with one or more children are declared with the
name of the children elements inside parentheses.

Example:

When children are declared in a sequence separated by


commas, the children must appear in the same sequence in
the document.
ELEMENTS WITH CHILDREN
In a full declaration, the children must also be declared,
and the children can also have children. The full
declaration of the “address” element is:
DECLARING ONLY ONE OCCURRENCE OF
AN ELEMENT
Syntax:

<!ELEMENT element-name (child-name)>

Example:

<!ELEMENT address (street)>

The child element street must occur once, and only once
inside the address element.
DECLARING MINIMUM ONE OCCURRENCE
OF AN ELEMENT
Syntax:

<!ELEMENT element-name (child-name+)>

Example:

<!ELEMENT address (street+)>

The + sign declares that the child element street must occur
one or more times inside the address element.
DECLARING ZERO OR MORE
OCCURRENCES OF AN ELEMENT
Syntax:

<!ELEMENT element-name (child-name*)>

Example:

<!ELEMENT address (street*)>

The * sign declares that the child element street can occur
zero or more times inside the address element.
DECLARING ZERO OR ONE OCCURRENCES
OF AN ELEMENT
Syntax:

<!ELEMENT element-name (child-name?)>

Example:

<!ELEMENT address (street?)>

The ? sign declares that the child element street can occur
zero or one time inside the address element.
DECLARING EITHER/OR CONTENT
Example:

<!ELEMENT note (to,from,header,(message|body))>

The example declares that the note element must contain a


to element, a from element, a header element, and either a
message or a body element.
DECLARING MIXED CONTENT
Example:

<!ELEMENT note (#PCDATA|to|from|header|message)*>

The example declares that the note element can contain


zero or more occurrences of parsed character data, to,
from, header, or message elements.
DECLARING ATTRIBUTES
Syntax:

<!ATTLIST element-name attribute-name attribute-type


attribute-value>
Example:

<!ATTLIST payment type CDATA "check">

XML example:

<payment type="check" />


ATTRIBUTE-TYPE
The attribute-type can be one of the following:
ATTRIBUTE-VALUE
The attribute-value can be one of the following:
A DEFAULT ATTRIBUTE VALUE
DTD:
<!ELEMENT square EMPTY>
<!ATTLIST square width CDATA "0">

Valid XML:

<square width="100" />

The square element is defined to be an empty element with


a width attribute of type CDATA. If no width is specified, it
has a default value of 0.
#REQUIRED
The #REQUIRED keyword could be used when you don’t
have an option for the default value, but still want to force
the attribute to be present.

<!ATTLIST element-name attribute-name attribute-type


#REQUIRED>

DTD:
<!ATTLIST person number CDATA #REQUIRED>

Valid XML Invalid XML


<person number="5677" /> <person />
#IMPLIED
The #IMPLIED keyword could be used if you don't want to
force the author to include an attribute, and you don't have
an option for a default value.

<!ATTLIST element-name attribute-name attribute-type


#IMPLIED>

DTD:
<!ATTLIST contact fax CDATA #IMPLIED>

Valid XML Valid XML


<contact fax="555-667788" /> <contact />
#FIXED
The #FIXED keyword could be used when you want an
attribute to have a fixed value without allowing the author
to change it. If an author includes another value, the XML
parser will return an error.
<!ATTLIST element-name attribute-name attribute-type
#FIXED "value">

DTD:
<!ATTLIST sender company CDATA #FIXED "Microsoft">

Valid XML Invalid XML


<sender company="Microsoft" /> <sender company= "Google" />
ENUMERATED ATTRIBUTE VALUES
Enumerated attribute values could be used when you want
the attribute value to be one of a fixed set of legal values.

<!ATTLIST element-name attribute-name (en1|en2|..)


default-value>

DTD:
<!ATTLIST payment type (check|cash) "cash">

Valid XML Invalid XML


<payment type="check" /> <payment type "card" />
THE END

You might also like