XML schema to help you model (2)

Xml

Compound type definitions, element and attribute declarations

In XML schemas, the representations are essentially different for those that allow elements to have their own content, as well as composite types that can carry their own properties and those that cannot have element content and attributes. In an instance document, there is a significant difference between the definition of a new type (whether simple or complex) and the declaration that allows elements and attributes to have specific names and types (whether simple or complex). In this section, you will describe in more detail how to define a composite type and how to declare elements and their attributes that use a composite type.

In a schema document, when you need to define a new composite type, you should use the complextype element to define it, which includes element declarations, element references, and attribute declarations. These elements are declared not so much as their own type, but as an association between the element names that are controlled by the associated schema and the type constraints that govern the representation of those element names in the instance document. Elements are declared by using element elements, and attributes are declared by using attribute elements. For example, usaddress is defined as a composite type, so it is seen in the USAddress type definition that it contains declarations of five elements and a declaration of a property (see Code 3).

<!--code 3 Composite Type definition Example: usaddress-->
<xsd:complextype name= "USAddress" >
<xsd:sequence>
<xsd:element name= "name" type= "xsd:string"/>
<xsd:element name= "Street" type= "xsd:string"/>
<xsd:element name= "City" type= "xsd:string"/>
<xsd:element name= "state" type= "xsd:string"/>
<xsd:element name= "Zip" type= "Xsd:decimal"/>
</xsd:sequence>
<xsd:attribute name= "Country" type= "Xsd:nmtoken" fixed= "US"/>
</xsd:complexType>

The implication of this definition is that any element in the instance document that is declared as usaddress (for example, Shiptto in Po.xml) must contain five elements and an attribute, and these elements must be named Name, Street, city, state, and zip. These names should be consistent with the value of the Name property of the element elements in the schema definition. And these elements must appear in the same order in the schema declaration, the first four elements must contain a string element content, and the fifth must contain the element contents of a decimal numeric type. An element declared as a usaddress type can have a country property that must contain the string "US".

The USAddress type definition contains only element declarations that refer to simple types, including string, Decimal, and NmToken. In contrast, the Purchaseordertype type definition (see Code 4) contains an element declaration that references a compound type, such as USAddress. Both types of declarations use the same type attribute to identify the type, without having to distinguish between simple or complex types.

<!--code 4 Composite Type definition example: Purchase ordertype-->
<xsd:complextype name= "Purchaseordertype" >
<xsd:sequence>
<xsd:element name= "ShipTo" type= "USAddress"/>
<xsd:element name= "BillTo" type= "USAddress"/>
<xsd:element ref= "comment" minoccurs= "0"/>
<xsd:element name= "Items" type= "items"/>
</xsd:sequence>
<xsd:attribute name= "OrderDate" type= "Xsd:date"/>
</xsd:complexType>

In the Purchaseordertype type definition, the declarations for the two child elements of ShipTo and BillTo associate different element names with the same compound type, which is usaddress. As a result of this definition, if any element that appears in an instance document (such as Po.xml), when the element type is declared as Purchaseordertype, then the element must contain two elements named ShipTo and BillTo, both of which contain five child elements ( Name, street, city, state, and Zip), the five child elements appear as part of the USAddress declaration. The ShipTo and BillTo elements can also contain country attributes, depending on the type definition of the usaddress.

The Purchaseordertype type definition contains a OrderDate property declaration, which, like the country property declaration in usaddress, is identified as a simple type. In fact, all attribute declarations must reference a simple type. This is because the attribute is different from the element declaration and cannot contain other elements or attributes.

To date, the element declaration we describe uses an existing type definition for each element name. Sometimes, however, it is more convenient to use an existing element than to define a new element by applying a type (see Code 5).

<!--code 5 defines element--> using an existing element reference
<xsd:element ref= "comment" minoccurs= "0"/>

Code 5 The element declaration definition refers to an existing element comment, which is defined in other parts of the purchase order schema document. In general, the value of a ref attribute must point to a global element. That is, it should be declared below the element, not as part of the compound type definition. The implication of the Code 5 declaration is that an element called comment can appear in the relevant part of the instance document about the definition, and its contents must be the same as the type of the referenced element, in this case "string".

Global Elements and attributes

Global elements and global properties are created when global declarations are made, and global declarations appear as direct child elements of elements. Once defined, the global element or global attribute can use the ref attribute reference in one or more element/attribute declarations as previously described. A declaration that refers to a global element in which the referenced element is allowed in the instance document to appear in the element associated with the declaration. So for example, the comment elements in Po.xml can also appear in the ShipTo, BillTo, and items elements, because declarations of compound type definitions that reference comment also appear in the declarations of these three elements.

The declaration of a global element also allows the element to appear as a top-level document element in the instance document, so the PurchaseOrder element, which is declared as a global element in PO.xsd, can appear as a top-level element in Po.xml. It is noteworthy that, based on this rationale, comment elements that appear as top-level elements in documents such as Po.xml are also allowed.

There are many restrictions on using global elements and attributes, one of which is that global declarations cannot contain references. Global declaration definitions cannot contain ref attributes, they must use the type attribute (or, as used in the example, follow an anonymous type definition). The second limitation is that constraints cannot be placed in global declarations, although they can be placed in local declarations that reference global declarations. In other words, global declarations cannot contain minoccurs, maxoccurs, or use attributes. The use of constraints is given in the next section.

Number of occurrences constraint

We see that the value of the minoccurs property in the element declaration in code 5 is 0, so the comment element is an option in the Purchaseordertype type. In general, an element must appear when its minoccurs value is 1 or more. The maximum number of elements that an element can appear is determined by the maxoccurs attribute in the declaration. This value may be a positive integer such as 1, or a large integer of 100, or a "unbounded" to indicate the maximum number of occurrences. The default values for the minoccurs and maxoccurs properties are 1. Therefore, when an element such as comment does not define a maxoccurs property, then the element cannot be present more than once. If you specify only the value of the minoccurs property, it must be less than the default value equal to maxoccurs, that is, minoccurs can only be 0 or 1 if it appears alone. This is because the valid value of the minoccurs must be less than the valid value equal to maxoccurs. Similarly, if you specify only the MaxOccurs property, it must be greater than or equal to the default value of minoccurs, that is, you must take a value of 1 or more. If all two properties are omitted, then the element must appear and appear only once.

For a property, it can have two choices: one occurrence or none at all, and no other occurrences. So the syntax for specifying the number of occurrences of a property differs from the syntax of the element. Specifically, a property declaration can use a using property to indicate whether a property needs to appear (see the Declaration of the Partnum property in code 2,po.xsd).

The default values for properties and elements are declared using the Defaults property, but this property has different semantics in different cases. When a property is declared with a default value, if the property appears in the instance document, then the value of the property is the value that the property appears in the instance document, that is, the value in the instance document is the final valid value. If the property does not appear in the instance document, the pattern processor will consider the value of this property to be equal to the value of the default property in the declaration. It is important to note that the property default value only makes sense when the property itself is "optional." If you specify a default value in the declaration, and you set the Use property to a value other than "optional" (that is, it must appear), the processor generates an error. That is, a property's default value takes effect only if the property does not appear in the instance document.

When a default value is defined in an element declaration, the pattern processor differs from the default value of the processing property when it handles default element values. If an element in an instance document appears with its own content, the value of the element is the content of the element in the instance document. If the element has no content, the schema processor considers the value of the element (content) to be equal to the value of the default property in the declaration. If the element does not appear in the instance document, the pattern processor does not consider the element to be present at all.

In summary, the distinction between element and attribute defaults can be considered to be applied when the attribute is not present, and when the element content is empty, the default element value is applied, and the default element value is not applied when the element does not appear.

Properties and element declarations, the fixed property is used to ensure that properties and elements are set to special values. If the po.xsd contains a declaration of a country attribute, the property declaration has a fixed property, and the value is us. This declaration means that the appearance of the country property in the instance document is optional (the default value for the Use property is optional), but if the property appears its value must be "us", and if the property does not appear, the mode processor automatically sets the country property value "us". It should be noted that the concept of fixed values and the concept of default values are mutually exclusive, and if the fixed and default properties are declared at the same time, the schema processor generates an error.

It is noteworthy that in the global element and attribute declarations, minoccurs, maxOccurs, and use do not appear or appear.