Introduction to XML for Database Developers - Simple Type Declarations
(Page 6 of 9 )
Types are XSD schema equivalents of data types. Simple types are XSD components that cannot contain xsd:elements and xsd:attributes. Some simple types like int, datetime, string, ID, IDREF, language, and gYear (Gregorian year) are defined along with the XML Schema in the xsd namespace, while others can be derived from them in the XSD schema (like user-defined data types in TSQL).
A new simple type is derived in an xsd:simpleType element:
<xsd:simpleType name="ProdYear">
<xsd:restriction base="xsd:gYear">
<xsd:minInclusive value="1990"/>
<xsd:maxInclusive value="2010"/>
</xsd:restriction>
</xsd:simpleType>
A new simple type is defined by a name (attribute) and a set of facets (elements) inside the xsd:restriction element. In this case, the minInclusive and maxInclusive facets define the range of acceptable years.
The enumeration facet can be used to define a lookup list (the list of acceptable values):
<xsd:simpleType name="CanProvince">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="ON"/>
<xsd:enumeration value="BC"/>
<xsd:enumeration value="MA"/>
<xsd:enumeration value="NB"/>
...
</xsd:restriction>
</xsd:simpleType>
The pattern facet uses regular expressions to define the format of values in the element:
<xsd:simpleType name="GUID">
<xsd:restriction base="xsd:string">
<xsd:pattern value="[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}
-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"/>
</xsd:restriction>
</xsd:simpleType>
In this case, the GUID type is defined as a set of 8, 4, 4, 4, and 12 hexadecimal digits divided by dashes (-).
The W3C Recommendation defines the following facets:
- length
- minLength
- maxLength
- pattern
- enumeration
- whiteSpace
- maxInclusive
- minInclusive
- maxExclusive
- minExclusive
- totalDigits
- fractionDigits
Naturally, you cannot use every facet with every type. Only some combinations make sense.
Complex Types Complex types are XSD schema elements that can be defined to contain additional attributes and elements. In the following example, the EqType complex type definition consists of two element declarations:
<xsd:complexType name="EqType">
<xsd:sequence>
<xsd:element name="EqTypeId" type="xsd:integer"/>
<xsd:element name="EqTypeName" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
The meaning of the xsd:sequence element is that both elements must be present in the sequence (order) in which they are declared.
Complex types can be built from other simple and complex types:
<xsd:complexType name="Equpment">
<xsd:sequence>
<xsd:element name="EqId" type="xsd:integer" minOccurs="1"/>
<xsd:element name="Make" type="string" minOccurs="1"/>
<xsd:element name="Model" type="string" minOccurs="1"/>
<xsd:element name="eqType" type="EqType" minOccurs="1"/>
<xsd:element ref="comment" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="guid" type="GUID"/>
</xsd:complexType>
The first three elements are defined as simple types, but the eqType element is defined as an instance of the EqType complex type defined earlier.
The first four elements are defined inline—the definition of each element also contains its type. There is an alternative means of defining elements: you can name an element in one place and reference it in another. For example, the comment element was named somewhere else in the schema and is only referenced here.
NOTE
The advantage of an inline definition is that it is more compact—the definition and the instance of an element are in the same place. The advantage of a named definition is that it can be referenced in many places.
Groups An xsd:group element allows you to define a set of xsd:elements that will later be referenced together. In the following example, the ExtendedPrice element has been defined as the group of Price, Currency, and Quantity elements:
<xsd:element name="OrderItem">
<xsd:complexType>
...
<xsd:group ref="ExtendedPrice"/>
...
</xsd:complexType>
</xsd:element>
...
<xsd:group name="ExtendedPrice">
<xsd:sequence>
<xsd:element name="Price" type="xsd:decimal"/>
<xsd:element name="Currency" type="xsd:string"/>
<xsd:element name="Quantity" type="xsd:decimal"/>
</xsd:sequence>
</xsd:group>
An attributeGroup element also allows you to define a group of attributes that can later be referenced together:
<xsd:element name="Equipment" maxOccurs="unbounded">
<xsd:complexType>
...
<xsd:attributeGroup ref="EquipmentProp"/>
...
</xsd:complexType>
</xsd:element>
...
<xsd:attributeGroup name="EquipmentProp">
<xsd:attribute name="Make" type="xsd:string"/>
<xsd:attribute name="Model" type="xsd:string"/>
<xsd:attribute name="EqType" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Monitor"/>
<xsd:enumeration value="Desktop"/>
<xsd:enumeration value="Keyboard"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:attributeGroup>
Annotating Schemas To add a comment to the schema, you can use the xsd:annotation element. It can contain two subelements. The xsd:documentation element is used to mark comments written for people, while the xsd:appinfo element is used to mark information for programs (such as style sheets and SQLXML). The content of the appinfo element should be well formed XML (so that target applications can parse them).
NOTE
It’s not that programs need a valid comment from the developer. The appinfo annotations simply do not have any meaning for the schema validator, while they might be very important instructions for target programs.
<xsd:annotation>
<xsd:documentation xml:lang="en-US">
This element should be linked with Location.LocId.
</xsd:documentation>
<xsd:appinfo>
<TbSql proc="Location.LocId">Link</TbSql>
</xsd:/appinfo>
<xsd:/annotation>
You should also use the xml:lang attribute inside the xsd:documentation element to indicate the language in which your comment is written.
Annotations can be placed only:
- Before and after any global component (such as schema, simpleType, and attribute)
- At the beginning of nonglobal components
Next: XSD Schema Tools >>
More MS SQL Server Articles
More By McGraw-Hill/Osborne
|
 This article was excerpted from chapter 13 of SQL Server 2000 Stored Procedure & XML Programming, second edition, written by Dejan Sunderic (McGraw-Hill/Osborne, 2004; ISBN: 0072228962). Check it out at your favorite bookstore today. Buy this book now.
|
|
/ 8 
