We have now discussed how to define new composite types (such as purchaseordertype ", declare elements (such as purchaseorder) and declarative properties (such as OrderDate). In these definitions, it is generally included, if we give two objects to give the same name? The answer depends on the two objects in the problem, and the more similar things are generally, they are more It is possible to cause conflicts.
Below, we give some examples to explain when the same name will result in a problem. If both objects are types, and define a composite type for ustetes, but also define a simple type USSTATES, conflicting conflicts. If the two objects are types and elements or types and properties, when a composite type called USAddress, an element is defined to be called USADDress, and there is no conflict. If two objects are different types of elements (generally, it is not a global element), when we declare a part of the element name as a USADRESS type, and the second element name is part of the ITEM type, there is no conflict ( Similar elements sometimes referred to as local elements declarations). Finally, if both objects are type, you define one of them yourself, and the XML Schema specification has built another one, such as defining a simple type called Decimal, then there is no conflict. The reason here is not named conflict because they belong to different namespaces.
Use simple type
In the purchase order mode document PO.xsd, there are several elements and attributes being declared as simple types. Some of these simple types such as String and Decimal are built into XML Schema, and some of them are derived from (if the language of the object technology is inherited) built-in type. For example, the type of partnum attribute is called SKU (STOCK Keeping Unit), which is from String. Built-in simple types and their subsequent versions can be used in all elements and attribute statements.
The new simple type is defined by the existing simple type (built-in simple type, and simple type from the built-in simple type). Typically, we lead to a new simple type by recovering an existing simple type. In other words, the new type of legitimate range is a subset of the existing value range. We use the SimpleType element to define and name a new simple type, use the Restriction element to indicate the existing base type, and use it to identify details of the constraint value range.
Suppose I want to create a new integer type called Myinteger, its value ranges from 10,000 to 99999. Then definition should be based on simple type Integer and then define its value range from 10,000 to 99999. In order to define Myinteger, this is to constrain the scope of Integer, see Code 6:
Examples of code 6 show a combination described by a basic type definition and two value domain intervals to implement the MYINTEGER implementation.
Previous Purchase Order Mode Documentation contains other examples of more detailed define simple types. A new simple type called SKU (see Code 7) is incorporated from (by constraint) simple type String. In addition, we use a description called Pattern, and the regular expression value "/ D {3} - [A-Z] {2}" of Pattern to constrain the value of the SKU. Among them, the semantic expression of the regular expression value is followed by a linked font, followed by two uppercase English letters.
XML Schema defines 15 elements for simple type definitions. In these elements, Enumeration is particularly useful, which can be used to constrain almost every simple type other than the Boolean type. Enumeration limits the value of a simple type of a series of different enumeration values. For example, we can use Enumeration to define a new type called usState (see Code 8), usState is taken from the String type, and its value must be an abbreviation for the US state.
USState will become a very good replacement of String types in the current State element declaration. By using this replacement, the State element can have the verification capability of the legal value. For example, the child elements State of Billto and Shipto elements will be limited in AK, Al, and AR. Note that the value of a particular type must be unique.
Anonymous type definition
Using XML Schema, we can define a range of names, such as the PurchaseOrDertype type. Then declare an element, such as the PurchaseOrder, is then applied by using the constructor such as "Type =". This type of mode is very straightforward, but some are not practical. In particular, if many types of only applying only once and contains very little constraints, in this case, a type should be able to be defined. Such a simple definition of the usual form is an anonymous type saving a name and external reference overhead.
In the definition of type Items in Po.xsd (see Code 9), two element declarations use an anonymous type definition, which is Item and Quantity. In general, you can determine anonymous element definition (or anonymous attribute definition) by whether you contain "Type =" in the element. If there is a type definition that is not named, it can also be considered an anonymous element (attribute) definition.
In the ITEM element, it is defined as a composite anonymous type. This complex type is made of ProductName, Quantity, USPRICE, Comment, Shipdate elements, and a property called PartNum. In Quantity Elements, it has a simple anonymous type to lead from the Integer type, its value ranges from 1 to 99.
