Definitive XML Schema (Charles F. Goldfarb Definitive Xml Series)
  • Definitive XML Schema (Charles F. Goldfarb Definitive Xml Series)
  • Definitive XML Schema (Charles F. Goldfarb Definitive Xml Series)

Definitive XML Schema (Charles F. Goldfarb Definitive Xml Series)

4.5 2
by Priscilla Walmsley, Prisilla Walmsley
     
 

View All Available Formats & Editions

The authoritative XML Schema reference and tutorial!

  • Leverage the full power of XML Schema!
  • In-depth coverage of the approved W3C Recommendation
  • Schema design–practical and thorough
  • Transition help for experienced DTD developers
  • Authoritative! By Priscilla Walmsley–a member of the W3C XML Schema Working Group

To

See more details below

Overview

The authoritative XML Schema reference and tutorial!

  • Leverage the full power of XML Schema!
  • In-depth coverage of the approved W3C Recommendation
  • Schema design–practical and thorough
  • Transition help for experienced DTD developers
  • Authoritative! By Priscilla Walmsley–a member of the W3C XML Schema Working Group

To leverage the full power of XML, companies need shared vocabularies to base their documents and scripts upon. XML Schema makes it possible to create those shared vocabularies-and Definitive XML Schema is the authoritative guide to the standard! Written by Priscilla Walmsley, a member of the W3C working group that created XML Schema, this book explains the W3C Recommendation with unprecedented insight and clarity–and introduces practical techniques for writing schemas to support any B2B, Web service, or content processing application. Coverage includes:

  • How XML Schema provides a rigorous, complete standard for modeling XML document structure, content, and datatypes
  • Working with schemas: Schema composition, instance validation, documentation, namespaces, and more
  • XML Schema building blocks: elements, attributes, and types
  • Advanced techniques: type derivation, model groups, substitution groups, identity constraints, redefinition, and much more
  • An in-depth primer on effective schema design, including naming, document structure, and extensibility considerations
  • Transition guidance for experienced DTD developers

Definitive XML Schema brings together expert guidance for schema design, superior approaches to schema development, and the most systematic XML Schema reference on the market. Whether you're a developer, architect, or content specialist, it's the only XML Schema resource you need!

"XML Schema is an incredibly powerful-and complex-document schema language, with such new capabilities as strong typing, modularity, inheritance, and identity constraints. This book guides you through the complexity so you can confidently use that power for your own projects."

–Charles F. Goldfarb

Read More

Editorial Reviews

Written by a member of the W3C working group that created the XML Schema for creating shared vocabularies, this book explains the W3C Recommendation from an insider's perspective and introduces practical techniques for writing schemas to support any business-to-business Web service. Walmsley, a software architect specializing in XML architecture and data management, shows how the XML Schema provides a standard for modeling XML document structure, explains how to work with schemas, and describes advanced techniques. She also provides an in-depth primer on effective schema design, and transition guidance for experienced DTD developers. Annotation c. Book News, Inc., Portland, OR (booknews.com)

Product Details

ISBN-13:
9780130655677
Publisher:
Prentice Hall
Publication date:
12/28/2001
Series:
Charles F. Goldfarb Definitive XML Series
Pages:
528
Product dimensions:
6.94(w) x 9.06(h) x 1.22(d)

Read an Excerpt

Chapter 9: Simple types

Both element and attribute declarations can use simple types to describe the data content of the components. This chapter introduces simple types, and explains how to define your own atomic simple types for use in your schemas.

9.1 Simple type varieties

There are three varieties of simple type: atomic types, list types, and union types.
  1. Atomic types have values that are indivisible, such as 10 and large.

  2. List types have values that are whitespace-separated lists of atomic values, such as <availableSizes>10 large 2</availableSizes>.

  3. Union types may have values that are either atomic values or list values. What differentiates them is that the set of valid values, or "value space," for the type is the union of the value spaces of two or more other simple types. For example, to represent a dress size, you may define a union type that allows a value to be either an integer from 2 through 18, or one of the string values small, medium, or large.
List and union types are covered in Chapter 11, "Union and list types."

9.1.1 Design hint: How much should I break down my data values?

Data values should be broken down to the most atomic level possible. This allows them to be processed in a variety of ways for different uses, such as display, mathematical operations, and validation. It is much easier to concatenate two data values back together than it is to split them apart. In addition, more granular data is much easier to validate. It is a fairly common practice to put a data value and its units in the same element, for example <length>3cm</length>. How-ever, the preferred approach is to have a separate data value, preferably an attribute, for the units, for example <length units="cm">3</length>.

Using a single concatenated value is limiting because:

  • It is extremely cumbersome to validate. You have to apply a complicated pattern that would need to change every time a unit type is added.

  • You cannot perform comparisons, conversions, or mathematical operations on the data without splitting it apart.

  • If you want to display the data item differently (for example, as "3 centimeters" or "3 cm" or just "3", you have to split it apart. This complicates the stylesheets and applications that process the instance document.
It is possible to go too far, though. For example, you may break a date down as follows:

<orderDate>
<year>2001</year>
<month>06</month>
<day>15</day>
</orderDate>

This is probably an overkill unless you have a special need to process these items separately.

9.2 Simple type definitions

9.2.1 Named simple types

Simple types can be either named or anonymous. Named simple types are always defined globally (i.e., their parent is always schema or redefine) and are required to have a name that is unique among the data types (both simple and complex) in the schema. The XSDL syntax for a named simple type definition is shown in Table 9�1.

The name of a simple type must be an XML non-colonized name, which means that it must start with a letter or underscore, and may only contain letters, digits, underscores, hyphens, and periods. You cannot include a namespace prefix when defining the type; it takes its namespace from the target namespace of the schema document. All of the examples of named types in this book have the word "Type" at the end of their names, to clearly distinguish them from element-type names and attribute names. However, this is not a requirement; you may in fact have a data type definition and an element declaration using the same name.

Example 9�1 shows the definition of a named simple type Dress-SizeType, along with an element declaration that references it. Named types can be used in multiple element and attribute declarations.

Example 9�1. Defining and referencing a named simple type

<xsd:simpleType name="DressSizeType">
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="2"/>
<xsd:maxInclusive value="18"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:element name="size" type="DressSizeType"/>

9.2.2 Anonymous simple types

Anonymous types, on the other hand, must not have names. They are always defined entirely within an element or attribute declaration, and may only be used once, by that declaration. Defining a type anonymously prevents it from ever being restricted, used in a list or union, or redefined. The XSDL syntax to define an anonymous simple type is shown in Table 9�2.

Example 9�2 shows the definition of an anonymous simple type within an element declaration.

Example 9�2. Defining an anonymous simple type

<xsd:element name="size">
<xsd:simpleType>
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="2"/>
<xsd:maxInclusive value="18"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>

9.2.3 Design hint: Should I use named or anonymous types?

The advantage of named types is that they may be defined once and used many times. For example, you may define a type named Product-CodeType that lists all of the valid product codes in your organization.

This type can then be used in many element and attribute declarations in many schemas. This has the advantages of:

  • encouraging consistency throughout the organization,
  • reducing the possibility of error,
  • requiring less time to define new schemas,
  • simplifying maintenance, because new product codes need only be added in one place.
Named types can also make the schema more readable, when the type definitions are complex.

An anonymous type, on the other hand, can be used only in the element or attribute declaration that contains it. It can never be redefined, have types derived from it, or be used in a list or union type. This can seriously limit its reusability, extensibility, and ability to change over time.

However, there are cases where anonymous types are preferable to named types. If the type is unlikely to ever be reused, the advantages listed above no longer apply. Also, there is such a thing as too much reuse. For example, if an element can contain the values 1 through 10, it does not make sense to try to define a data type named OneToTen-Type that is reused by other unrelated element declarations with the same value space. If the value space for one of the element declarations that uses the named data type changes, but the other element declarations do not change, it actually makes maintenance more difficult, because a new data type needs to be defined at that time.

In addition, anonymous types can be more readable when they are relatively simple. It is sometimes desirable to have the definition of the data type right there with the element or attribute declaration....

Read More

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >