This gave rise to XML. XML was designed to take some of the power of SGML but make it simpler and easier to use. The goal of the original working group was "80/20", that is, to get 80% of the functionality of SGML with only 20% of the complexity. With the XML 1.0 Recommendation, it seemed that XML would achieve the 80/20 goal, but then a confusing array of related technologies entered the picture: XML Namespaces, XSL, XSLT, XPath, XPointer, XQuery, and eventually XML Schema.
XML is growing more and more complex everyday. Many XML experts lament the situation and view the current set of XML-related standards as growing chaotically out of control. One expert lamented, "As if Internet time weren't fast enough, now we seem to have XML time!" The result is that recommendations coming from the W3 C are seemingly increasing in complexity, and decreasing in the time spent contemplating them.
Many of the recommendations are mired in controversy, with the XML community divided into two camps: those who want recommendations that include every possible usage of the language, and those who are still dedicated to the 80/20 philosophy. XML Schema are certainly mired in the simplicity versus comprehensiveness debate as well.
The controversy surrounding XML Schema has followed the technology around from conference to conference, and even resulted in the development of competing technologies such as RELAX (REgular LAnguage for Xml) and TREX (Tree Regular Expressions for XML). These technologies are gaining a growing following, even though they are not specifications which originate from or are even being considered by the W3 C.
XML Schema are a very useful technology, but how and why you might choose to use XML Schema varies widely.
No one schema mechanism suits all applications of XML. It is virtually impossible to imagine one technology that addresses all of the potential uses for XML.
Such is the case with XML Schema. Some of you will delve into XML Schema only to find that you barely need to scratch the surface in order to accomplish your needs. Others will read this entire book only to find that Schema simply don't do everything you need. Others may find that an alternative technology, such as RELAX NG or Schematron or even the "older" Document Type Definitions (DTDs), is better at solving your particular problems.
Note
The controversy over which features to include in XML Schema and the level of complexity gave birth to several suggested alternatives, including RELAX, TREX, Schematron, and so on. Already, RELAX and TREX have been combined into RELAX NG, and as time passes there will certainly be more shakeouts in the alternative schema world. We will discuss alternatives to the XML Schema Recommendation more in Chapter 18, and in the Appendixes.
That's why this book sets out to accomplish two goals: not only to explain to you the syntax and language of XML Schema, but also to educate you about the why of XML Schema. It is as important, if not more important, to know when you need to use a Schema as it is to know how. By working your way through the sections of this book, you'll get a solid understanding of what schema are, why you would want to use them, and finally, how you would write a schema in the XML Schema language.
The first step is to look at what brought the XML Schema Recommendation into being in the first place and understand why it is such a political beast.
The best way to understand what a schema is is to think of it like grammar. A schema is a set of requirements that need to be met in order for a document or set of data, which is all a document really is, to be a valid expression within the context of that grammar.
For example, take a look at the English language. A formal sentence in English needs to contain a subject and a verb. You can think of that basic constraint on a sentence (that it must contain a subject and a verb) as a schema. If you were to write that as a rule, you could say:
A formal English sentence must contain a subject and a verb.
Now, working within that structure, you can have a sentence as simple as "I am," which contains only two words-"I" being the subject, and "am" being the verb. But you will notice that our grammar rule doesn't specify that a sentence can't contain other words, such as adjectives and adverbs. So we could write "I am tired," or "I am sleeping soundly," and those would both be valid formal sentences because they still contain a subject and a verb.
Looking at this model, it's easy to see how grammar can become complex very quickly. For example, what if you wanted to specify that a sentence could have more than one subject? What if you wanted to specify the use of direct objects or indirect objects? You could quickly and easily outgrow your simple grammar.
That's what schema design is all about: designing the best grammar to describe your document or data. It is really an art more than a science, much like computer programming. And it is an area that inspires debate. There are camps that believe in the grammar model, and there are camps that believe in a rules-based model. A grammar model lends itself to more flexibility, in both design and interpretation, while a strict, rules-based system offers more precision, and might be easier to implement.
Grammars express structure while still allowing for a flexible data model. However, strict rules can have valid applications as well. When you need generic guidelines for forming sentences, a grammar works great. But what if you wanted to say that any time the subject of a sentence was "Steve" then the verb had to be "went"? That would be best accomplished with a rule. (Not "Steve drove to the store" but "Steve went to the store.") Now, if the subject were "Mary", we could still say "Mary drove to the store," because that doesn't violate the rule. The level of granularity is specific enough that a loosely formed grammar would not be as restrictive as a rules-based system would be.
These are the types of issues that surround the world of XML and the debate around XML Schema. As we delve into the world of schema, and as you begin to write your own, you will need to address these issues in order to get the most out of XML. XML Schema do provide a mechanism for defining grammars, and some mechanisms for rules as well. But if strict rules are what you are after, XML Schema might get you into some tricky situations.
You may or may not already be familiar with the concept of validation. XML documents can be validated using a Document Type Definition, or DTD. In fact, DTDs are actually a type of schema. A DTD is not actually a separate document, even though most people use a DTD as an external subset. To the XML parser, however, the DTD is still part of the XML document, specifically the part that allows you to specify the structure of the document. Within the DTD you can define your elements, the attributes for those elements, and other facets of your XML document, such as how many times an element can occur.
Document Type Definitions are a holdover from the days of SGML. However, DTDs when used with XML are more limited than what can be accomplished using DTDs with SGML. DTDs basically provide a mechanism for specifying elements, attributes, entities, and notations. Now, that does not mean that DTDs are not useful. In fact, there are many applications of XML where DTDs are more than powerful enough....
Introduction.
I.
1. An Overview of
The Politics of
2. Schema Structure.
Schema Are
Element. Using Namespaces in Schema. Comparing a DTD and an
3. Converting a DTD into a Schema.
The Legacy of Document Type Definitions. Differences Between DTDs and Schema. A Simple Airline Ticket Itinerary DTD. Converting the DTD to a Schema. The Finished Schema. Resources for Converting DTDs. Conclusions. In the Real World.
II.
4. The Components of
Introducing Components. Handling Names with Schema. General Constraints and Validation Rules. Type Definitions. Element Schema Components. Attribute Schema Components. Notations. Particles, Model Groups, and Annotations. Conclusions. In the Real World.
5. Element Declarations.
The Importance of Elements. Defining Elements with Schema. &#lt;element&#gt; Properties. Constraining Elements with Attributes. Content Models. &#lt;simpleType&#gt;. &#lt;complexType&#gt;. Substitution Groups. Conclusion. In the Real World.
6. Attributes.
Attributes Are Fundamental. Attribute Properties. Defining Attributes with Schema. attributeGroup. anyAttribute. Built-in Attributes. Conclusion. In the Real World.
7. Model Groups.
Model Groups and Schema Content. What Is a Model Group? Particles. Defining Model Groups. Wildcards. Notations. Annotations. Conclusions. In the Real World.
8. Example Schema: A Contact Schema.
Building an
III.
9. Introducing Datatypes.
What Is a Datatype? How Datatypes Function in Schema Namespaces and Datatypes. Primitive and Derived Datatypes. Built-In and User-Derived Datatypes. Facets. Atomic, List, and Union Datatypes. Conclusion. In the Real World.
10. Primitive Datatypes.
Introducing Primitive Datatypes. string. boolean. Numeric Datatypes. Date and Time Datatypes. Binary Datatypes. anyURI. QName. NOTATION. Conclusion. In the Real World.
11. Derived Datatypes.
Built-In Derived Datatypes. normalizedString. token. language. Backward Compatibility. Name. integer. long. int. short. byte. Conclusion. In the Real World.
12. Representing and Modeling Data.
Working with Data. Deriving Simple Types. Deriving Complex Types. Anonymous Versus Named Types. Scope. Abstract Types. Controlling Derived Types. Uniqueness. Regular Expressions and
13. Example Schema: Customer Invoice.
Outlining the Schema Requirements. Defining the Datatypes. Writing the Schema. Conclusion. In the Real World.
IV. DEVELOPING A PURCHASE ORDER SCHEMA.
14. Building Multipart Schema
Advantages of Multipart Schema. Combining Multiple Schema into a Single Schema. Type Libraries. Working with Namespaces. An Example: The Invoice Schema Revisited. Conclusions. In the Real World.
15. An Example Schema: Human Resources.
Outlining the Project. The Scenario. A Sample Instance Document. Establishing Relationships. Summarizing Components. Establishing the Datatypes. Planning the Multiple Schema. Conclusions. In the Real World.
16. Building and Using the Schema.
Getting Started. The Modular Approach. Bringing It All Together. Using the Schema. Conclusions. In the Real World.
17.
Schema Best Practices. Multipart Schema. Elements and Datatypes. Scope Issues. Namespaces. Best Practices Resources. Conclusions. In the Real World.
18. Schema Alternatives and Future Directions.
TREX. RELAX. Schematron. OASIS and Schema. RELAX NG. The Semantic Web. Conclusion. In the Real World.
V. APPENDIXES.
Appendix A. Schema Resources.
Appendix B. Schema Alternatives: TREX.
Introducing TREX. Structure of a TREX Pattern. Elements in TREX. Attributes in TREX. Datatypes in TREX. Modularity and Reuse. Features Not Included in TREX. A TREX Example. Conclusion.
Appendix C. Schema Alternatives: RELAX.
Introducing RELAX. The RELAX Core. A RELAX Document. Elements in RELAX. Attributes in RELAX. Advanced Roles. Datatypes in RELAX. Other RELAX Features. Missing Features. A Sample RELAX Document. Conclusion.
Appendix D. Schema Alternatives: Schematron.
Introduction to Schematron. XSLT and XPath. Schematron Basics. Integrating Schematron with
Index.
Overview