XML Schema helps you model (3)

We have now discussed how to define new composite types (such as purchaseordertype), declared elements (such as purchaseorder), and declared attributes (such as orderdate ). In these defined behaviors, names are generally included. What will happen if we give two objects the same name? The answer depends on the two objects in the question. Generally, the closer the two objects are, the more likely they are to cause conflicts.

Next, we will give some examples to illustrate when the same name will cause problems. If both objects are of the type, and a composite type is defined as usstates, and a simple type is defined as usstates, a conflict occurs. If two objects are types, elements, or types and attributes, when a composite type is defined as usaddress and an element is defined as usaddress, there is no conflict. If two objects are different types of elements (generally not global elements), when we declare an element name as part of the usaddress type, and the second element name is part of the item type, so there is no conflict (similar elements are sometimes called Partial Element declarations ). Finally, if both objects are of a type, you define one of them, and the XML Schema Specification defines another one. For example, you define a simple type called decimal, there is no conflict at this time. There is no naming conflict here because they belong to different namespaces.


Simple Type


In the Po. XSD document of the purchase order mode, several elements and attributes are declared as simple types. Some simple types such as string and decimal are built-in in XML schema, while others are built-in types (if the language using object technology is inherited. For example, the partnum attribute is of the type SKU (stock keeping unit), which is derived from a string. Built-in simple types and their subsequent versions can be used in all element and attribute declarations.

New simple types are defined by existing simple types (built-in simple types and simple types derived from built-in simple types. Generally, a new simple type is introduced by re-binding an existing simple type. In other words, the valid value range of the new type is a subset of the value range of the existing type. We use the simpletype element to define and name the new simple type, use the restriction element to indicate the existing base type, and use it to identify the details of the restricted value range.

Assume that you want to create a new integer type called myinteger. Its value range is 10000 to 99999. The definition should be based on the simple type Integer and then define its value range to 10000 to 99999. To define myinteger, the range of integer is restricted. See Code 6:

<! -- Code 6 uses the base type to define a new simple type -->
<XSD: simpletype name = "myinteger">
<XSD: Restriction base = "XSD: integer">
<XSD: min‑sive value = "10000"/>
<XSD: maxcompute sive value = "99999"/>
</XSD: Restriction>
</XSD: simpletype>



The example in code 6 shows a combination of a basic type definition and two value ranges. These three elements are used to implement the definition of myinteger.

The previous Purchase Order Mode document contains other examples of defining simple types in more detail. A new simple type called SKU (see Code 7) is derived from a string of the simple type (through constraints. In addition, we use a description called pattern and the regular expression value of pattern '/d {3}-[A-Z] {2}' to constrain the SKU value. The semantics of the regular expression value is three digits followed by a font size, followed by two uppercase letters.

<! -- Code 7 Simple SKU type definition -->
<XSD: simpletype name = "SKU">
<XSD: Restriction base = "XSD: string">
<XSD: Pattern value = "/d {3}-[A-Z] {2}"/>
</XSD: Restriction>
</XSD: simpletype>



XML schema defines 15 elements for simple type definition descriptions. Among these elements, enumeration is particularly useful and can be used to constrain almost every simple type except the boolean type. Enumeration limits values of simple types to a series of different enumerated values. For example, we can use enumeration to define a new type called usstate (see code 8). usstate is derived from the string type and its value must be abbreviated as the U.S. state name.

<! -- Code 8 simple usstate type definition -->
<XSD: simpletype name = "usstate">
<XSD: Restriction base = "XSD: string">
<XSD: enumeration value = "AK"/>
<XSD: enumeration value = "Al"/>
<XSD: enumeration value = "Ar"/>
<! -- And so on... -->
</XSD: Restriction>
</XSD: simpletype>



Usstate will be a very good replacement product of the string type in the current State element declaration. By using this replacement product, the state element can be verified with valid values. For example, the state of subelements of the billto and shipto elements will be restricted to AK, Al, and AR. Note that the enumerated values of a specific type must be unique.


Anonymous Type Definition


Using XML schema, we can define a series of types with names, such as purchaseordertype. Then declare an element, such as purchaseorder, to apply the type by using a constructor such as "type =. This type of pattern is very straightforward to construct, but some are not practical. In particular, if you define many types that only apply once and contain very few constraints, in this case, a type should be more easily defined. Such a simple definition usually takes the form of an anonymous type that saves the name and external reference overhead.

In the definition of type items in Po. XSD (see Code 9), two element declarations use anonymous type definitions, which are item and quantity. Generally, you can determine the definition of an anonymous element (or an anonymous attribute) by checking whether the element contains the "type =" attribute ). If there is a type definition without a name, it can also be considered as an anonymous element (attribute) Definition.

<! -- Code 0-9 Po. XSD mode definition -->
<XSD: complextype name = "items">
<XSD: sequence>
<XSD: element name = "item" minoccurs = "0" maxoccurs = "unbounded">
<XSD: complextype>
<XSD: sequence>
<XSD: element name = "productname" type = "XSD: string"/>
<XSD: element name = "quantity">
<XSD: simpletype>
<XSD: Restriction base = "XSD: positiveinteger">
<XSD: maxexclusive value = "100"/>
</XSD: Restriction>
</XSD: simpletype>
</XSD: Element>
<XSD: element name = "usprice" type = "XSD: decimal"/>
<XSD: Element ref = "comment" minoccurs = "0"/>
<XSD: element name = "shipdate" type = "XSD: Date" minoccurs = "0"/>
</XSD: sequence>
<XSD: attribute name = "partnum" type = "SKU" use = "required"/>
</XSD: complextype>
</XSD: Element>
</XSD: sequence>
</XSD: complextype>



In the item element, it is defined as a composite anonymous type. This complex type is composed of productname, quantity, usprice, comment, shipdate elements, and an attribute called partnum. In the quantity element, it has a simple anonymous type derived from the integer type, and its value range is 1 to 99.