|Oracle8i Application Developer's Guide - XML
Release 3 (8.1.7)
Part Number A86030-01
Introduction to Oracle XML, 18 of 27
W3C has chartered a Schema working group to provide a new, XML based notation for structural schema and datatypes as an evolution of the current Document Type Definition (DTD) based mechanism. XML Schemas can be used for the following:
XML Schema API is not provided with this release. However, you can download it from OTN.
Datatypes themselves can either be primitive (such as bytes, dates, integers, sequences, intervals) or user-defined (including ones that are derived from existing datatypes and which may constrain certain properties -- range, precision, length, mask -- of the basetype.) Application-specific constraints and descriptions are allowed.
XML Schema provides inheritance for element, attribute, and datatype definitions. Mechanisms are provided for URI references to facilitate a standard, unambiguous semantic understanding of constructs. The schema language also provides for embedded documentation or comments.
For example, you can define a simple data type as shown in "XMLSchema Example 1: Defining a Simple Data Type".
This is an example of defining a simple data type in XMLSchema:
It is clear even from the simple example above that XMLSchema provides a number of important new constructs over DTDs -- such as a basetype, and a `minimum value' constraint.
When dynamic data is generated from a database, it is typically expressed in terms of a database type system. In Oracle, this is the object-relational type system described above, which provides for much richness in data types -- such as NULL-ness, variable precision, such as, NUMBER(7,2), check constraints, user-defined types, inheritance, references between types, collections of types and so on. XML Schema can capture a wide spectrum of schema constraints that go towards better matching generated documents to the underlying type-system of the data.
Consider the simple Purchase Order type expressed in XML Schema:
<type name="Address" > <element name="street" type="string" /> <element name="city" type="string" /> <element name="state" type="string" /> <element name="zip" type="string" /> </type> <type name="Customer"> <element name="custNo" type="positiveInteger"/> <element name="custName" type="string" /> <element name="custAddr" type="Address" /> </type> <type name="Items"> <element name="lineItem" minOccurs="0" maxOccurs="*"> <type> <element name="lineItemNo" type="positiveInteger" /> <element name="lineItemName" type="string" /> <element name="lineItemPrice" type="number" /> <element name="LineItemQuan"> <datatype basetype="integer"> <minExclusive>0</minExclusive> </datatype> </element> </type> </element> </type> <type name="PurchaseOrderType"> <element name="purchaseNo" type="positiveInteger" /> <element name="purchaseDate" type="date" /> <element name="customer" type="Customer" /> <element name="lineItemList" type="Items" /> </type>
These XML Schemas have been deliberately constructed to match closely the Object-Relational purchase order example described above in"XML Example 2: XML Document Produced from Generic Mapping" . The point is to underscore the closeness of match between the proposed constructs of XML Schema with SQL:1999-based type systems. Given such a close match, it is relatively easy for us to map an XML Schema to a database Object-Relational schema, and map documents that are schema-valid according to the above schema to row objects in the database schema. In fact, the greater expressiveness of XML Schema over DTDs greatly facilitates the mapping.
The applicability of the schema constraints provided by XML Schema is not limited to data-driven applications. There are more and more document-driven applications that exhibit dynamic behavior. A simple example might be a memo, which is routed differently based on markup tags. A more sophisticated example is a technical service manual for an intercontinental aircraft. Based on complex constraints provided by XML Schema, one can ensure that the author of such a manual always enters a valid part-number, and one might even ensure that part-number validity depends on dynamic considerations such as inventory levels, fluctuating demand and supply metrics, or changing regulatory mandates.