XML schema to help you model (3)

XML naming conflict

We have now discussed how to define new composite types (such as Purchaseordertype), declare elements (such as PurchaseOrder), and declare attributes (such as OrderDate). In these defining behaviors, which are generally named, what will happen if we give the same name to two objects? The answer depends on the two objects in the problem, which, in general, are more likely to cause conflicts, as the two objects become more similar.

Below, we give some examples to show when the same name can cause problems. If two objects are of type and a compound type is defined as Usstates, and a simple type is defined as usstates, there is a conflict. If two objects are types and elements or types and attributes, when a compound type is defined as usaddress, and an element is defined as a usaddress, there is no conflict at this time. 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 as part of the item type, there is no conflict at this time (similar elements are sometimes called local element declarations). Finally, if two objects are of type, and you define one of them, and the XML Schema specification has a built-in definition of another, such as defining a simple type called decimal, no conflict occurs at this time. There is no naming conflict here because they belong to different namespaces.

Using simple types

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

The new simple type draws a definition from an existing simple type (built-in simple type and a simple type that originates from a built-in simple type). Typically, we draw a new simple type by constraining an existing simple type. In other words, the legal value range of the new type is a subset of the range of values for the existing type. We use the simpletype element to define and name the new simple type, use the restriction element to point out the existing base type, and use it to identify the details of the scope of the constraint value.

Suppose you want to create a new integer type called Myinteger, which has a range of values ranging from 10000 to 99999. The definition should be based on a simple type integer and then define a range of values ranging from 10000 to 99999. To define Myinteger, this constrains the scope of the integer, see Code 6:

<!--code 6 uses a base type to define a new simple type-->
<xsd:simpletype name= "Myinteger" >
<xsd:restriction base= "Xsd:integer" >
<xsd:mininclusive value= "10000"/>
<xsd:maxinclusive value= "99999"/>
</xsd:restriction>
</xsd:simpleType>

The example in code 6 shows a combination of a basic type definition and a range of two ranges, through which the myinteger is defined by the three elements.

The previous Purchase Order mode documentation contains other more detailed examples of defining simple types. A new simple type called SKU (see Code 7) is derived from a simple type string (through constraints). In addition, we use a description called pattern, and the regular expression value "\d{3}-[a-z]{2}" for the type to constrain the value of the SKU. Where the value of the regular expression is semantically 3 digits followed by a hyphen followed by two uppercase letters in English.

<!--code 7 SKU Simple Type definition-->
<xsd:simpletype name= "SKU" >
<xsd:restriction base= "Xsd:string" >
<xsd:pattern value= "\d{3}-[a-z]{2}"/>
</xsd:restriction>
</xsd:simpleType>

The XML schema defines 15 elements for a simple type definition description. In these elements, enumeration is particularly useful and can be used to constrain almost every simple type except the Boolean type. Enumeration a value that restricts a simple type is a series of different enumeration 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 an abbreviation for the U.S. state name.

<!--code 8 usstate Simple 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 become a very good replacement for string type in the current state element declaration. By using this replacement, the state element can have a checksum capability of a legal value. For example, the element state of the BillTo and ShipTo elements will be restricted to AK, AL, and AR. Note the enumeration value for a particular type must be unique.

Anonymous type definition

Using XML schemas, we can define a series of types with names, such as the Purchaseordertype type. Then declare an element, such as purchaseorder, to apply the type by using a construction method such as "type=". This type of pattern construction is straightforward, but somewhat impractical. In particular, if you define a number of types that are applied only once and contain very few constraints, in this case a type should be more simply defined. The common form of such a simple definition is an anonymous type that saves the cost of name and external references.

In the definition of type items in PO.xsd (see Code 9), there are two element declarations that use anonymous type definitions, which are item and quantity. In general, you can determine an anonymous element definition (or an anonymous attribute definition) by including whether the element contains a "type=" attribute. If a type definition with no name appears, it can also be considered 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= "/>"
</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. The complex type is made up of ProductName, quantity, Usprice, comment, shipdate elements, and a property called Partnum. In the quantity element, it has a simple anonymous type that is drawn from the integer type, and its value ranges from 1 to 99.