Understanding XML Schema: XML Schema (I ))

Ben ArticleThe series will work with examples to describe XML schema, which is an entry-level overview of the currently international standard XML modeling tool, we hope that you can learn how to use XML schema and the specific semantics of XML schema document instances through this series. This article mainly introduces the use of namespaces in XML Schema. around the use of namespaces, it describes the scope of the schema and the ability of namespaces to limit elements/attributes. Under the namespace restrictions, the global element/attribute Declaration and the local element/attribute Declaration have different usage methods and functions. This article introduces their different positioning in the same target namespace, the special usage of the target namespace is also introduced.

A schema document can be seen as a set of Type Definitions and element declarations (Vocabulary). Their names belong to a specified namespace, which is called the target namespace. The target namespace allows us to differentiate definitions and declarations from different vocabulary. For example, the target namespace enables us to differentiate the element declarations in the XML schema language vocabulary and element declarations in another hypothetical chemical language vocabulary. The former makes part of the target namespace "http://www.w3.org/2001/XMLSchema", while the latter is another namespace.

When we want to check whether an instance document matches one or more mode documents (through a process called mode verification ), we need to determine which elements and attributes are declared and defined in the schema definition should be used to check the elements and attributes in the instance document. In this process, the target namespace plays a very important role.

The authors of the mode document also have several optional ways to influence how the element and attribute identifiers behave in the instance document. More specifically, by using a clear or default namespace prefix, the author can determine whether the partial declaration elements and attributes that appear in the instance document must be verified by a namespace constraint. The authors of the pattern document have many influences on the selection of constraints on local elements and attributes, the structure of the pattern document, and the consideration of the instance document, the following sections describe several important aspects.

Target namespace and undefined local elements/attributes

In the new version of the Order Mode document po1.xsd (relative to the PO in the previous article in the XML schema preliminary. XSD), we explicitly declare a target namespace, and specify that the locally defined elements and attributes must be infinitely set. The target namespace in po1.xsd is "http://www.example.com/PO1" and is displayed as the value of the property targetnamespace.

The limitations of local elements and attributes can be globally specified. This is achieved through a pair of attributes of Schema elements, elementformdefault and attributeformdefault. The other method is to use the form attribute in each local declaration separately. All similar property values can be set to "unqualified" or "qualified" to indicate whether the elements and attributes of the local Declaration must be unrestricted.

In po1.xsd, by setting elementformdefault and attributeformdefault to "unqualified", we specify the elements and attributes at the global level. Strictly speaking, these settings are not mandatory because the default values of these two attributes are. Here we declare that they are to highlight the comparison between this application method and the situation we described later:

To view how the target namespace of this mode document is filled, we should check the definition of each type and the declaration of elements in sequence. Before the schema element ends, we first define a type of usaddress, which consists of the element name, street, and so on. One result of this type definition is that the usaddress type must be included in the target namespace of the mode document. Then, we define the type purchaseordertype, which consists of shipto, billto, and comment elements. Purchaseordertype is also included in the target namespace of the mode document. Note that the type reference in the three element declarations has a prefix, Po: usaddress. Po: usaddress and Po: Comment. At the same time, the namespace prefix is associated with the namespace "http://www.example.com/po1. This namespace is the same as the target namespace of this mode document. Therefore, the handler of this mode document will know the definition of usaddress and comment element in this mode document. Of course, we can also use different target namespaces to reference types in other modes. Therefore, you can reuse external definitions and declarations in the schema document.

At the beginning of the mode document po1.xsd, we declared the elements purchaseorder and comment, which are included in the target namespace of the mode document. The purchaseorder element type has a namespace prefix. Similarly, usaddress has a namespace prefix. In contrast, the Comment element type and string have no namespace prefix. The po1.xsd schema document contains a default namespace declaration. Therefore, the types without the namespace prefix, such as string, and elements such as element. And complextype, are associated with the default namespace "http://www.w3.org/2001/xmlschema. In fact, this is the target namespace of the XML schema. Therefore, a po1.xsd processor knows how to find the definition of the string type and the declaration of element. In the XML schema. Now, let's take a look at how the target namespace of this mode document affects the consistency of an instance document:

<? XML version = "1.0"?> <APO: purchaseorder xmlns: APO = "http://www.example.com/PO1" orderdate = ""> <shipto Country = "us"> <Name> Alice Smith </Name> <Street> 123 Maple Street </street> <! -- Etc. --> </shipto> <billto Country = "us"> <Name> Robert Smith </Name> <Street> 8 oak Avenue </street> <! -- Etc. --> </billto> <APO: Comment> hurry, my lawn is going wild! </APO: Comment> <! -- Etc. --> </APO: purchaseorder>

In this instance document, declare a namespace "http://www.example.com/PO1" and associate it with the namespace prefix "APO. This prefix is used to limit the two elements of the document: purchaseorder and comment. This namespace is consistent with the target namespace of the pattern document in po1.xsd. Therefore, the processor of an instance document will know the declaration that the purchaseorder and comment should be searched in the mode document po1.xsd. In fact, the reason for naming the target namespace is that there is a target namespace for the purchaseorder and comment. The target namespace in the mode document controls the validation of the corresponding namespace in the instance document.

The prefix "APO:" is applied to the global elements purchaseorder and comment. In addition, elementformdefault and attributeformdefault require that the namespace prefix is not used in every element of the partial declaration, such as shipto, billto, name, and street, it is not used in any attribute (all attributes are declared locally ). Both purchaseorder and comment are global elements, because they exist as direct sub-elements of Schema elements, rather than declared in a special type of content. For example, in po1.xsd, The purchaseorder statement appears as a direct sub-element of the schema element. However, the shipto statement appears as a sub-element of the complextype element that defines the purchaseordertype.

When local elements and attributes do not need to be limited, the author of an instance document needs to know more or less details about the mode document to create a mode document to verify the instance document. More specifically, if the author can limit that only root elements (such as purchaseorder) are global, simply Limit root elements. In contrast, the author may know that all elements are declared globally. Therefore, all elements in the instance document can be prefixed with namespaces. In this case, the default namespace declaration may be used. On the other hand, if global and local declarations do not have a uniform pattern, the author needs to understand the pattern details to correctly Add a proper namespace prefix to global elements and attributes.

Back to Top

Limited local elements and attributes

Although we can describe the limitation of partial elements at the beginning, elements and attributes can still be requested to be independently qualified. To specify that all elements declared locally in the schema document must be limited, you can set the value of elementformdefault to "qualified:

<Schema xmlns = "http://www.w3.org/2001/XMLSchema" xmlns: po = "http://www.example.com/PO1" targetnamespace = "http://www.example.com/PO1" elementformdefault = "qualified" attributeformdefault = "unqualified"> <element name = "purchaseorder" type = "Po: purchaseordertype "/> <element name =" comment "type =" string "/> <complextype name =" purchaseordertype "> <! -- Etc. --> </complextype> <! -- Etc. --> </Schema>

In this instance document, which is consistent with the above model document, we explicitly limit all elements:

<? XML version = "1.0"?> <APO: purchaseorder xmlns: APO = "http://www.example.com/PO1" orderdate = ""> <APO: shipto Country = "us"> <APO: Name> Alice Smith </APO: name> <APO: Street> 123 Maple Street </APO: Street> <! -- Etc. --> </APO: shipto> <APO: billto Country = "us"> <APO: Name> Robert Smith </APO: Name> <APO: street> 8 oak Avenue </APO: Street> <! -- Etc. --> </APO: billto> <APO: Comment> hurry, my lawn is going wild! </APO: Comment> <! -- Etc. --> </APO: purchaseorder>

Of course, we can also use the implicit limitation provided by the default namespace for each element to replace explicit limitation, as shown in po2.xml below:

<? XML version = "1.0"?> <Purchaseorder xmlns = "http://www.example.com/PO1" orderdate = "1999-10-20"> <shipto Country = "us"> <Name> Alice Smith </Name> <Street> 123 Maple Street </street> <! -- Etc. --> </shipto> <billto Country = "us"> <Name> Robert Smith </Name> <Street> 8 oak Avenue </street> <! -- Etc. --> </billto> <comment> hurry, my lawn is going wild! </Comment> <! -- Etc. --> </purchaseorder>

In po2.xml, all elements in the instance document belong to a namespace, And the namespace statement declares a default namespace, which is applied to all elements in the instance document. Therefore, explicit prefixes are not required for any element.

The attribute limitation is very similar to the element limitation. If the attribute is declared as a global attribute or attibuteformdefault is set to "qualified", the attribute must be limited and will appear in the instance document with the namespace prefix. An example of a qualified attribute is "xsi: Nil". In fact, the attributes to be qualified must be explicitly prefixed with the namespace, because the description of XML-namespaces does not provide the default namespace mechanism for attributes. In the instance document, attributes can appear without a prefix. attributes do not need to be qualified. Generally, this is a typical application scenario.

For this limitation mechanism, we have described so far how to declare all the local elements and attributes in a specific target namespace. At the same time, we can also define a declaration by using the form attribute declaration. For example, to limit the publickey attribute declared in the instance documentation, we can use the following method to declare it:

<Schema xmlns = "http://www.w3.org/2001/XMLSchema" xmlns: Po = "http://www.example.com/PO1" targetnamespace = "http://www.example.com/PO1" elementformdefault = "qualified" attributeformdefault = "unqualified"> <! -- Etc. --> <element name = "secure"> <complextype> <sequence> <! -- Element declarations --> </sequence> <attribute name = "publickey" type = "base64binary" form = "qualified"/> </complextype> </element> </Schema>

Note that in the above mode document, we use the form attribute to replace the value of attributeformdefault for the publickey attribute. Similarly, form attributes can be used in element declarations. The following is an example of an instance document that is consistent with the preceding mode document:

<? XML version = "1.0"?> <Purchaseorder xmlns = "http://www.example.com/PO1" xmlns: Po = "http://www.example.com/PO1" orderdate = ""> <! -- Etc. --> <secure Po: publickey = "gpm7"> <! -- Etc. --> </secure> </purchaseorder>

Back to Top

Global declaration and local Declaration

Another mode: When all element names are unique in a namespace, you can create such a mode document, all elements in this mode document are global. This method is the same as it is used in DTD. In the following example, we modified the original po1.xsd so that all elements are declared globally. In this example, we ignore the attributes of elementformdefault and attributeformdefault, this is to emphasize that their values are irrelevant when only global elements and attribute declarations exist.

This "Global" version of po1.xsd will correctly validate our instance document po2.xml, as we described earlier, this document can also be verified by the previous "qualified" version po1.xsd. In other words, both schema methods can correctly verify the same instance document with the default namespace. On the one hand, the design methods of these two models are similar. On the other hand, the writing methods of these two models are quite different. In particular, when all elements are declared as global elements, the advantages of local naming cannot be used. For example, for a global element, you can declare only one global element "title ". However, for a local element, you can declare the local element "title". It has a string type and is a sub-element of "book. In the same schema document (with the same target namespace), you can declare the second element, also known as "title", with a table value "Mr Mrs ms ".

Back to Top

Undeclared target namespace

In the previous XML Schema preliminary article, we used the schema document without declaring the target namespace and the instance document without declaring the namespace to explain the basic knowledge of XML schema. At this time, a problem occurs naturally. In the examples of these mode documents and instance documents, what is the target namespace and where are they referenced?

In the purchase order mode document Po. in XSD, we do not declare a target namespace for the schema document, nor do we declare the namespace prefix associated with the target namespace of the schema document ("Po:" above :"), in general, if you have a namespace prefix, you can view the definition and declaration of types and elements in the schema document in this namespace. If the target namespace is not declared in the mode document, the result is the definition and declaration in this mode document. For example, both usaddress and purchaseorder are references without namespaces. In other words, there is no clear namespace prefix applied to references, and no default namespace is implicitly applied to references. In this example, the purchaseorder element references the definition of the type purchaseordertype to implement the Declaration. In contrast, all XML Schema elements and types used in Po. XSD are defined by the namespace prefix "XSD:" associated with the XML schema namespace.

When the mode document is designed to have no target namespace, we strongly recommend that all XML Schema elements and types Use a prefix of the namespace associated with the XML schema namespace, such as "XSD:" To clearly define implementation restrictions (such as in Po. in XSD ). The basic principle we recommend is that if the XML schema elements and types are by default associated with the XML schema namespace, such as not using the namespace prefix, therefore, the reference of the XML schema type may not be different from that of the custom type.

You can use the element declaration in a schema document without a target namespace to verify that there are no elements with a limited namespace prefix in the instance document. That is to say, they can be used to verify elements that are not provided with namespace restrictions. These elements do not have a clear namespace prefix or a default namespace prefix. Therefore, to verify a traditional XML 1.0 document that does not use a namespace, you must provide a schema document with no target namespace. Of course, there are many XML 1.0 documents that do not use namespaces, so there will be many schema documents that do not fill in the target namespace.

Back to Top

Summary

This article mainly introduces the use of namespaces in XML Schema. around the use of namespaces, it describes the scope of the schema and the ability of namespaces to limit elements/attributes. Under the namespace restrictions, the global element/attribute Declaration and the local element/attribute Declaration have different usage methods and functions. This article introduces their different positioning in the same target namespace, the special usage of the target namespace is also introduced.

References

• Web Service technology/comment website
  • WebServices. org is a comprehensive Web Service technology website.
  • IBM developerworks/Web service zone, IBM Web Service Technical Resource Center
  • Msdn Online Web Services developer resources, Microsoft Web Service developer resource website

• Web Service series technical standards and specifications
  • XML Schema Part 1: ures, W3C, 2 May 2001
  • XML Schema Part 2: datatypes, W3C, 2 May 2001

Address: http://www.ibm.com/developerworks/cn/xml/x-schema/part3/index.html