- Simple type varieties
- Simple type definitions
- Simple type restrictions
- Facets
- Preventing simple type derivation
This chapter is from the book
This chapter is from the book
This chapter is from the book
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 DressSizeType, along with an element declaration that references it. Named types can be used in multiple element and attribute declarations.
Table 9–1 XSDL syntax: named simple type definition
|
Name |
|||
|
simpleType |
|||
|
Parents |
|||
|
schema, redefine |
|||
|
Attribute name |
Type |
Required/ default |
Description |
|
id |
ID |
|
unique ID |
|
name |
NCName |
required |
simple type name |
|
final |
"#all" | list of
("extension" |
"restriction" |
"list" | "union")
|
defaults to finalDefault of schema |
whether other types can be derived from this one, see Section 9.5 |
|
Content |
|||
|
annotation?, (restriction | list | union) |
|||
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.
Table 9–2 XSDL syntax: anonymous simple type definition
|
Name |
|||
|
simpleType |
|||
|
Parents |
|||
|
element, attribute, restriction, list, union |
|||
|
Attribute name |
Type |
Required/default |
Description |
|
id |
ID |
|
unique ID |
|
Content |
|||
|
annotation?, (restriction | list | union) |
|||
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 ProductCodeType 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 OneToTenType 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.