As I Have already mentioned and describe in my previous post about DTD. Prior to further elaborating more on XML schema or XSD. I first want to give a concise indication on how decisive the XML schema is in conditions of Validation of data which is very crucial.
To iterate again 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.
Document Type Definitions (DTDs) and XML Schemas are key technologies in this area. Although neither is strictly required for XML development, both DTDs and XML Schemas are important parts of the XML toolbox. DTDs have been around for over twenty years as a part of SGML, while XML Schemas are relative newcomers. Though they use very different syntax and take different approaches to the task of describing document structures, both mechanisms definitely occupy the same turf. The W3C seems to be grooming XML Schemas as a replacement for DTDs, but it isn't yet clear that how quickly the transition will be made. DTDs are here-and-now, while XML Schemas, in large part, are for the future.
Data Type Problems
Validation
A valid document includes a document type declaration that identifies the DTD the document satisfies. The DTD lists all the elements, attributes, and entities the document uses and the contexts in which it uses them. The DTD may list items the document does not use as well. Validity operates on the principle that everything not permitted is forbidden. Everything in the document must match a declaration in the DTD. If a document has a document type declaration and the document satisfies the DTD that the document type declaration indicates, then the document is said to be valid. If it does not, it is said to be invalid.
There are many things the DTD does not say. In particular, it does not say the following:
· What the root element of the document is
· How many of instances of each kind of element appear in the document
· What the character data inside the elements looks like
· The semantic meaning of an element; for instance, whether it contains a date or a person's name
DTDs allow you to place some constraints on the form an XML document takes, but there can be quite a bit of flexibility within those limits. A DTD never says anything about the length, structure, meaning, allowed values, or other aspects of the text content of an element.
Validity is optional. A parser reading an XML document may or may not check for validity. If it does check for validity, the program receiving data from the parser may or may not care about validity errors. In some cases, such as putting records into a database, a validity error may be quite serious, indicating that a required field is missing, for example. In other cases, rendering a web page perhaps, a validity error may not be so important, and you can work around it. Well-formedness is required of all XML documents; validity is not. Your documents and your programs can use it or not as you find it beneficial.
A Simple DTD Example
Example1.1 A DTD for the person
<!ELEMENT person (name, profession*)>
<!ELEMENT name (first_name, last_name)>
<!ELEMENT first_name (#PCDATA)>
<!ELEMENT last_name (#PCDATA)>
<!ELEMENT profession (#PCDATA)>
This DTD example above would probably be stored in a separate file from the documents it describes. This allows it to be easily referenced from multiple XML documents. However, it can be included inside the XML document if that's convenient, using the document type declaration. If it is stored in a separate file, then that file would most likely be named person.dtd, or something similar. The .dtd extension is fairly standard though not specifically required by the XML specification. If this file were served by a web server, it would be given the MIME media type application/xml-dtd.
Each line of example above is an element declaration. The first line declares the element; the second line declares the personname element; the third line declares the first_name element; and so on. However, the line breaks aren't relevant except for legibility. Although it's customary to put only one declaration on each line, it's not required. Long declarations can even span multiple lines.
The first element declaration in example above states that each person element must contain exactly one name child element followed by zero or more profession elements. The asterisk after profession stands for "zero or more." Thus, every person must have a name and may or may not have a profession or multiple professions. However, the name must come before all professions. For example, this person element is valid:
<person>
<name>
<first_name>John </first_name>
<last_name>Duffles</last_name>
</name>
</person>
However, this person element is not valid because it omits the name:
<person>
<profession>computer scientist</profession>
<profession>mathematician</profession>
<profession>cryptographer</profession>
</person>
This person element is not valid because a profession element comes before the name:
<person>
<profession>computer scientist</profession>
<name>
<first_name>Alan</first_name>
<last_name>Turing</last_name>
</name>
<profession>mathematician</profession>
<profession>cryptographer</profession>
</person>
The person element may not contain any element except those listed in its declaration. The only extra character data it can contain is whitespace. For example, this is an invalid person publication element: element because it adds a
<person>
<name>
<first_name>Alan</first_name>
<last_name>Turing</last_name>
</name>
<profession>mathematician</profession>
<profession>cryptographer</profession>
<publication>On Computable Numbers...</publication>
</person>
This is an invalid person element because it adds some text outside the allowed children:
<person>
<name>
<first_name>Alan</first_name>
<last_name>Turing</last_name>
</name>
was a <profession>computer scientist</profession>,
a <profession>mathematician</profession>, and a
<profession>cryptographer</profession>
</person>
In all these examples of invalid elements, you could change the DTD to make these elements valid. All the examples are well-formed, after all. However, with the DTD in example 1.1, they are not valid.
The name declaration says that each name element must contain exactly one first_namelast_name element. All other variations are forbidden. element followed by exactly one
The remaining three declarations--first_name, last_name, and profession--all say that their elements must contain #PCDATA. This is a DTD keyword standing for parsed character data --that is, raw text possibly containing entity references such as & and <, but not containing any tags or child elements.
In the example 1.1placed the most complicated and highest-level declaration at the top. However, that's not required. For instance in example 1.2 below is an equivalent DTD that simply reorders the declarations. DTDs allow forward, backward, and circular references to other declarations.
Example 1-2. An alternate DTD for the person element
<!ELEMENT last_name (#PCDATA)>
<!ELEMENT profession (#PCDATA)>
<!ELEMENT name (first_name, last_name)>
<!ELEMENT person (name, profession*)>
Example 1-3. A valid person document
<?xml version="1.0" standalone="no"?>
<!DOCTYPE person SYSTEM "http://www.cafeconleche.org/dtds/person.dtd">
<person>
<name>
<first_name>John Duffles</first_name>
<last_name>John Duffles</last_name>
</name>
<profession>computer scientist</profession>
<profession>mathematician</profession>
<profession>cryptographer</profession>
</person>
XML Schemas
A Simple XML Schema
Below is a simple XML schema, which is made up of one complex type element with two child simple type elements
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Author">
<xs:complexType>
<xs:sequence>
<xs:element name="FirstName" type="xs:string" />
<xs:element name="LastName" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
As you can see, an XML schema is an XML document and must follow all the syntax rules of any other XML document; that is, it must be well formed. XML schemas also have to follow the rules defined in the "Schema of schemas," which defines, among other things, the structure of and element and attribute names in an XML schema.
Although it is not required, it is a common practice to use the xs qualifier to identify Schema elements and types we have to validate it first which I will show below.
The document element of XML schemas is xs:schema. It takes the attribute xmlns:xs with the value of http://www.w3.org/2001/XMLSchema, indicating that the document should follow the rules of XML Schema. This will be clearer after you learn about namespaces.
In this XML schema, we see a xs:element element within the xs:schema element. xs:elementAuthor as a complex type element, which contains a sequence of two elements: FirstName and LastName, both of which are of the simple type, string. is used to define an element. In this case it defines the element
Validating an XML Instance Document
As I have explained on the above code there is an example of a simple XML schema, which defined the structure of an Author element. The code sample below shows a valid XML instance of this XML schema.
<?xml version="1.0"?>
<Author xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="Author.xsd">
<FirstName>John</FirstName>
<LastName>Duffles</LastName>
</Author>
The above code is a simple XML document. Its document element is Author, which contains two child elements: FirstName and LastName, just as the associated XML schema requires.
The xmlns:xsi attribute of the document element indicates that this XML document is an instance of an XML schema. The document is tied to a specific XML schema with the xsi:noNamespaceSchemaLocation attribute.
Reference: Eric van der Vlist (2002) Dyanamic The W3C's Object-Oriented Descriptions for XML (page 5-10)[Online] Viewed at [http://oreilly.com/catalog/9780596002527/preview]
