XML Schema helps you model
XML Schema is a recommended standard for W3C (World Wide Web Alliance), officially released in May 2001. After several years of large-scale discussions and development, it is now laid, and it is the preferred data modeling tool in the world's recognized XML environment. Since XML is a subset of SGML (standard universal label language), it also inherits SGML for modeling DTD. The advantage of using DTD is to take advantage of a large number of existing DTD tools, making it a relatively low level to develop applications. However, DTD has a lot of defects: 1. DTD is based on regular expressions, and the description ability is limited; 2. DTD has no data type support, in most application environments; 3. DTD constraint definition ability is insufficient, unable Detailed semantic restrictions on the XML instance document; 4. DTD is not structured, the cost of reuse is relatively high; 5. DTD is not using XML as a description method, and the construction of DTD does not have a standard programming interface, cannot be DTD maintenance is performed using standard programming. XML Schema is designed for the shortcomings of these DTDs, which use XML as a descriptor, which has strong description capabilities, extension capabilities, and processing maintenance. XML Schema Introduction The main purpose of XML Schema is to define a class XML document (an XML Application). Therefore, the "example document" form of the mode is often used to describe an XML document consistent with a particular XML Schema. In fact, document instances and Schema documents do not exist in the form of documents, which can exist in the form of byte streams transmitted between applications, or as a collection of database records and XML "information items". However, in order to simplify the entry, we always regard examples and patterns as documentation or files, think they always exist in the form of a document instance or a mode document. Here we will combine an example to make a simple summary of XML Schema, I hope that you can use the usage method for the initial master of this section and the specific semantics of the XML Schema document instance. XML Schema is a basic tool for web services technology, but not all features of XML Schema will be used extensively, and therefore, this article will not be introduced for the system of XML Schema. Before introducing the XML Schema syntax, first consider an XML instance document PO.xml. It describes a home product purchase order generated by home product procurement / payment applications (see Code 1).
This purchase order consists of a heel element PurchaseORDER and its sub-elements Shipto, BillTo, Comment and Items. These sub-elements (except for Comment) also contain some other child elements. The leaf element is included in a number rather than any child element, such as a child element such as USPRice. Elements are called composite types if they contain sub-elements or with attributes; vice verses if only numbers, strings, or other data, etc., but are not included in the simple type. In this instance document, the composite type and some simple types are defined in the mode document that purchase the order, while the simple types of other standards are the form of simple types built in XML Schema. Introduce the contact between the purchase order instance document and the mode document before studying the purchase order mode documentation of this instance document. An instance document actually does not necessarily need a reference mode document. Of course, in fact, many instance documents do reference the mode document, in order to make the entry make it simpler, and we choose not to reference. At the same time, it is assumed that the processor of any instance document does not receive any information from the purchase order instance document, and can also correctly purchase the order mode document. Purchase Order Mode Documents in Code 2, give the mode document for purchasing orders. Document PO.xSD Before giveing an explanation, you can use XML knowledge to try to understand this mode document.
Purchase Order Mode Document consists of a Schema element and a series of sub-elements. Most sub-elements are Element, ComplexType, and SimpleType, which determines the expression and content of the elements in the instance document, everyone can read Element, ComplexType, SimpleType These elements, these will be several elements we have always needed. At the same time, you can declare XMLns: XSD = "http://www.w3.org/2001/xmlschema" by using the namespace in the Schema element, making each element in the pattern document has a namespace with XML Schema Contact Name Space Prefix "XSD:". Although in the grammatical, any prefix form can be used, but the namespace prefix "XSD:" is agreed to represent the XML Schema namespace. Since the same prefix is used, the same association will appear in the name of the built-in simple type, such as XSD: String. This form of association is to indicate that the current element or simple type is built-in definition of XML Schema language instead of a mode document author's own vocabulary. In order to clearly and briefly, we only mention the names and simple type names of elements, and ignore their prefix "XSD:". Composite type definitions, elements, and attributes declarations in XML Schema, for those who have their own content, and composite types that can carry their own properties, with simple types that cannot have element content and attributes, their representations have essentials different. In the instance document, there is a significant difference between the declarations that can create new types (regardless of simple and complex) definitions and allow elements and attributes (whether simple or complex) declarations (whether or not, complex). In this section, the composite type will be defined, and how to declare the elements of the composite type and its properties are described in more detail. In a mode document, when you need to define a new composite type, you should use the ComplexType element to be defined, such typical definitions include element declarations, elements reference, and attribute declarations. These elements declare that they are their own type, as well as the correlation between the element name controlled by the related mode and the type of constraint that controls these elements in the form of the example document. The element is declared by using the ELEMENT element, the attribute is declared by using the Attribute element. For example, USADDRESS is defined as a composite type, so it sees that it contains five elements declarations and a statement that it contains five elements (see Code 3).
In the type definition of the PurchaseOrDertype, the declaration of two sub-elements of Shipto and Billto is associated with the same compound type, which is usaddress. The result of this definition is that if any elements (such as PO.xml) appearing in the instance document, when the element type is declared as PurchaseOrDertype, then this element must contain two elements called Shipto and Billto, these two Elements must contain five sub-elements (Name, Street, City, State and Zip), which appears as part of the USADRESS statement. According to the related type definition of USAddress, Shipto and Billto elements can also include Country properties. The PURCHASEORDERTYPE type definition contains an ORDERDATE attribute declaration, just like the country property declaration in USAddress, it is identified as a simple type. In fact, all attribute declarations must reference the simple type. This is because attributes are different from the element declaration, and it cannot contain other elements or properties. To date, the elements we describe declare that each element name uses an existing type definition. Sometimes, using an existing element is more convenient than applying a type (see Code 5).
As a result of the number of times, we see that the value of the Minoccurs property is 0 in the element declaration in code 5, so the Comment element is an option in the PurchaseOrDertype type. In general, when the value of the MinoCCURS of an element is 1 or more, the element must appear. The maximum number of elements can appear is determined by the maxoccurs attribute in the statement. This value may be a positive integer such as 1, or a large integer 100, or in the form of "unbounded" to indicate that the number of unlimited appearances. The default value for the Minoccurs and Maxocus properties is 1. Therefore, when an element is as Comment, it does not define the maxoccurs property, then this element cannot be more than once. If only the Minoccurs property value is specified, it must be less than equivalent to the default value of MaxocCurs, that is, if Minoccurs appears separately, the value can only be 0 or 1, because the effective value of MinoCurs must be less than equivalent to Maxoccurs value. Similarly, if only the maxoccurs property is specified, it must be greater than or equal to the default value of Minoccurs, that is, the value must be 1 or more. If both attributes are omitted, the elements must appear and only once. For attributes, it can have two options: once or not, there is no other number of occurrences. Therefore, the syntax of the specified attributes has different symnages of the elements. It is important to note that the attribute statement can use a USE property to indicate whether the attribute needs to appear (see the declaration of the partnum attribute in PO.xsd). The default values of attributes and elements are declared using the default property, but this property has different semantics in different situations. When an attribute is declared using the default value, if the attribute appears in the instance document, the value of the attribute is the value that the attribute 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 mode processor will consider the value of this attribute equal to the value of the default property in the declaration. It should be noted that the attribute default value is only meaningful when the attribute itself is "optional". If in the statement, the default value is specified, but also sets the USE attribute to other values other than "optional" (that is, the appearance), the processor will generate errors. That is, the default value of the attribute is only effective when the property does not appear in the instance document. When there is a default value defined in an element declaration, the mode processor has some differences between the default elements value, compared to the default value of the processing attribute. If the element in the instance document occurs and with its own content, the value of the element is the content of the elements in the instance document. If the element is not content, the mode processor thinks that the value of this element is equal to the value of the default attribute in the declaration. If the element does not appear in the instance document, the mode processor does not think that the element appears at all. In summary, the difference between the element and the attribute default value can be considered to be applied when the default attribute value is applied when the attribute does not appear; when the element content is empty, the default element value is applied; when the elements do not appear, the default Element values are not applied. In the property and element declaration, the Fixed property is used to ensure that attributes and elements are set to a special value. As the declaration of a country property is included in Po.xsd, the property declaration has a fixed property, the value is US. This declaration means that the appearance of the country property in the instance document is optional (the default value of the USE property is optional), but if the value appears in the property, it must be "US"; if the attribute does not appear, the mode processor will automatically set Country property value is "US".
It should be noted that the concept of fixed values and the concept of default values is mutually exclusive. If the Fixed and Default properties are declared, the Mode processor will generate an error. It is worth noting that in the global element and attribute statement, Minoccurs, Maxoccurs, but no name conflicts can also appear.
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. Using a simple type in the purchase order mode document PO.xsd, there are several elements and properties 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. To define Myinteger, let's restrict 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.
In addition to using the built-in list type, you can create new list types by reference to existing atomic types (you cannot use existing list types to create new list types, and you cannot use composite types to create new list types. ). For example, we can build a list type named Myinteger and use it in the instance document (see Code 10). The second half of the code 10 is an example element consistent with the list type listofmyintType in the instance document.
