`

XML:XML Schema Part 0: Primer Second Edition

XMLIBM 
阅读更多

W3C

XML Schema Part 0: Primer Second EditionW3C Recommendation http://www.w3.org/TR/xmlschema-0/

<!--* <h2><a id="w3c-doctype" name="w3c-doctype" />W3C Recommendation 2 May 2001, Second Edition 28 October 2004</h2> *-->
Latest version:
Editors:
David C. Fallside, IBM <fallside@us.ibm.com>
Priscilla Walmsley <pwalmsley@datypic.com> - Second Edition

AbstractXML Schema Part 1: Structures and XML Schema Part 2: Datatypes provide the complete normative description of the XML Schema language. This primer describes the language features through numerous examples which are complemented by extensive references to the normative texts.

XML Schema Part 0: Primer is a non-normative document intended to provide an easily readable description of the XML Schema facilities, and is oriented towards quickly understanding how to create schemas using the XML Schema language.

Status of this DocumentW3C technical reports index at http://www.w3.org/TR/.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the

This is a W3C Recommendation, the first part of the Second Edition of XML Schema. This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

This document has been produced by the W3C XML Schema Working Group as part of the W3C XML Activity. The goals of the XML Schema language are discussed in the XML Schema Requirements document. The authors of this document are the members of the XML Schema Working Group. Different parts of this specification have different editors.

This document was produced under the 24 January 2002 Current Patent Practice (CPP) as amended by the W3C Patent Policy Transition Procedure. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.

The English version of this specification is the only normative version. Information about translations of this document is available at http://www.w3.org/2001/05/xmlschema-translations.

This second edition is not a new version, it merely incorporates the changes dictated by the corrections to errors found in the first edition as agreed by the XML Schema Working Group, as a convenience to readers. A separate list of all such corrections is available at http://www.w3.org/2001/05/xmlschema-errata.

The errata list for this second edition is available at http://www.w3.org/2004/03/xmlschema-errata.

Please report errors in this document to www-xml-schema-comments@w3.org (archive).

Table of ContentsIntroduction
2 Basic Concepts: The Purchase Order
2.1 The Purchase Order Schema
2.2 Complex Type Definitions, Element & Attribute Declarations
2.3 Simple Types
2.4 Anonymous Type Definitions
2.5 Element Content
2.6 Annotations
2.7 Building Content Models
2.8 Attribute Groups
2.9 Nil Values
3 Advanced Concepts I: Namespaces, Schemas & Qualification
3.1 Target Namespaces & Unqualified Locals
3.2 Qualified Locals
3.3 Global vs. Local Declarations
3.4 Undeclared Target Namespaces
4 Advanced Concepts II: The International Purchase Order
4.1 A Schema in Multiple Documents
4.2 Deriving Types by Extension
4.3 Using Derived Types in Instance Documents
4.4 Deriving Complex Types by Restriction
4.5 Redefining Types & Groups
4.6 Substitution Groups
4.7 Abstract Elements and Types
4.8 Controlling the Creation & Use of Derived Types
5 Advanced Concepts III: The Quarterly Report
5.1 Specifying Uniqueness
5.2 Defining Keys & their References
5.3 XML Schema Constraints vs. XML 1.0 ID Attributes
5.4 Importing Types
5.5 Any Element, Any Attribute
5.6 schemaLocation
5.7 Conformance

1

AppendicesAcknowledgements
B Simple Types & their Facets
C Using Entities
D Regular Expressions
E Index
E.1 XML Schema Elements
E.2 XML Schema Attributes

A

1 Introduction1 and 2 of the XML Schema specification. The intended audience of this document includes application developers whose programs read and write schema documents, and schema authors who need to know about the features of the language, especially features that provide functionality above and beyond what is provided by DTDs. The text assumes that you have a basic understanding of XML 1.0 and Namespaces in XML. Each major section of the primer introduces new features of the language, and describes those features in the context of concrete examples.

This document, XML Schema Part 0: Primer, provides an easily approachable description of the XML Schema definition language, and should be used alongside the formal descriptions of the language contained in Parts

Basic Concepts: The Purchase Order (§2) covers the basic mechanisms of XML Schema. It describes how to declare the elements and attributes that appear in XML documents, the distinctions between simple and complex types, defining complex types, the use of simple types for element and attribute values, schema annotation, a simple mechanism for re-using element and attribute definitions, and nil values.

Advanced Concepts I: Namespaces, Schemas & Qualification (§3), the first advanced section in the primer, explains the basics of how namespaces are used in XML and schema documents. This section is important for understanding many of the topics that appear in the other advanced sections.

Advanced Concepts II: The International Purchase Order (§4), the second advanced section in the primer, describes mechanisms for deriving types from existing types, and for controlling these derivations. The section also describes mechanisms for merging together fragments of a schema from multiple sources, and for element substitution.

Advanced Concepts III: The Quarterly Report (§5) covers more advanced features, including a mechanism for specifying uniqueness among attributes and elements, a mechanism for using types across namespaces, a mechanism for extending types based on namespaces, and a description of how documents are checked for conformance.

In addition to the sections just described, the primer contains a number of appendices that provide detailed reference information on simple types and a regular expression language.

The primer is a non-normative document, which means that it does not provide a definitive (from the W3C's point of view) specification of the XML Schema language. The examples and other explanatory material in this document are provided to help you understand XML Schema, but they may not always provide definitive answers. In such cases, you will need to refer to the XML Schema specification, and to help you do this, we provide many links pointing to the relevant parts of the specification. More specifically, XML Schema items mentioned in the primer text are linked to an index [Index (§E)] of element names and attributes, and a summary table of datatypes, both in the primer. The table and the index contain links to the relevant sections of XML Schema parts 1 and 2.

2 Basic Concepts: The Purchase Orderpo.xml

The purpose of a schema is to define a class of XML documents, and so the term "instance document" is often used to describe an XML document that conforms to a particular schema. In fact, neither instances nor schemas need to exist as documents per se -- they may exist as streams of bytes sent between applications, as fields in a database record, or as collections of XML Infoset "Information Items" -- but to simplify the primer, we have chosen to always refer to instances and schemas as if they are documents and files.

Let us start by considering an instance document in a file called . It describes a purchase order generated by a home products ordering and billing application:

Example
The Purchase Order, po.xml
<?xml version="1.0"?>
<purchaseOrder orderDate="1999-10-20">
   <shipTo country="US">
      <name>Alice Smith</name>
      <street>123 Maple Street</street>
      <city>Mill Valley</city>
      <state>CA</state>
      <zip>90952</zip>
   </shipTo>
   <billTo country="US">
      <name>Robert Smith</name>
      <street>8 Oak Avenue</street>
      <city>Old Town</city>
      <state>PA</state>
      <zip>95819</zip>
   </billTo>
   <comment>Hurry, my lawn is going wild<!/comment>
   <items>
      <item partNum="872-AA">
         <productName>Lawnmower</productName>
         <quantity>1</quantity>
         <USPrice>148.95</USPrice>
         <comment>Confirm this is electric</comment>
      </item>
      <item partNum="926-AA">
         <productName>Baby Monitor</productName>
         <quantity>1</quantity>
         <USPrice>39.98</USPrice>
         <shipDate>1999-05-21</shipDate>
      </item>
   </items>
</purchaseOrder>
next sub-section

The purchase order consists of a main element, purchaseOrder, and the subelements shipTo, billTo, comment, and items. These subelements (except comment) in turn contain other subelements, and so on, until a subelement such as USPrice contains a number rather than any subelements. Elements that contain subelements or carry attributes are said to have complex types, whereas elements that contain numbers (and strings, and dates, etc.) but do not contain any subelements are said to have simple types. Some elements have attributes; attributes always have simple types.

The complex types in the instance document, and some of the simple types, are defined in the schema for purchase orders. The other simple types are defined as part of XML Schema's repertoire of built-in simple types.

Before going on to examine the purchase order schema, we digress briefly to mention the association between the instance document and the purchase order schema. As you can see by inspecting the instance document, the purchase order schema is not mentioned. An instance is not actually required to reference a schema, and although many will, we have chosen to keep this first section simple, and to assume that any processor of the instance document can obtain the purchase order schema without any information from the instance document. In later sections, we will introduce explicit mechanisms for associating instances and schemas.

2.1 The Purchase Order Schemapo.xsd

The purchase order schema is contained in the file :

Example
The Purchase Order Schema, po.xsd
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <xsd:annotation>
    <xsd:documentation xml:lang="en">
     Purchase order schema for Example.com.
     Copyright 2000 Example.com. All rights reserved.
    </xsd:documentation>
  </xsd:annotation>

  <xsd:element name="purchaseOrder" type="PurchaseOrderType"/>

  <xsd:element name="comment" type="xsd:string"/>

  <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>

  <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>

  <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="100"/>
                </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>

  <!-- Stock Keeping Unit, a code for identifying products -->
  <xsd:simpleType name="SKU">
    <xsd:restriction base="xsd:string">
      <xsd:pattern value="\d{3}-[A-Z]{2}"/>
    </xsd:restriction>
  </xsd:simpleType>

</xsd:schema>
schema

The purchase order schema consists of a element and a variety of subelements, most notably element, complexType, and simpleType which determine the appearance of elements and their content in instance documents.

Each of the elements in the schema has a prefix xsd: which is associated with the XML Schema namespace through the declaration, xmlns:xsd="http://www.w3.org/2001/XMLSchema", that appears in the schema element. The prefix xsd: is used by convention to denote the XML Schema namespace, although any prefix can be used. The same prefix, and hence the same association, also appears on the names of built-in simple types, e.g. xsd:string. The purpose of the association is to identify the elements and simple types as belonging to the vocabulary of the XML Schema language rather than the vocabulary of the schema author. For the sake of clarity in the text, we just mention the names of elements and simple types (e.g. simpleType), and omit the prefix.

previous sub-section next sub-section2.2 Complex Type Definitions, Element & Attribute DeclarationsOccurrence Constraints
2.2.2 Global Elements & Attributes
2.2.3 Naming Conflicts

2.2.1

In XML Schema, there is a basic difference between complex types which allow elements in their content and may carry attributes, and simple types which cannot have element content and cannot carry attributes. There is also a major distinction between definitions which create new types (both simple and complex), and declarations which enable elements and attributes with specific names and types (both simple and complex) to appear in document instances. In this section, we focus on defining complex types and declaring the elements and attributes that appear within them.

New complex types are defined using the complexType element and such definitions typically contain a set of element declarations, element references, and attribute declarations. The declarations are not themselves types, but rather an association between a name and the constraints which govern the appearance of that name in documents governed by the associated schema. Elements are declared using the element element, and attributes are declared using the attribute element. For example, USAddress is defined as a complex type, and within the definition of USAddress we see five element declarations and one attribute declaration:

Example
Defining the USAddress Type
<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>
po.xml

The consequence of this definition is that any element appearing in an instance whose type is declared to be USAddress (e.g. shipTo in ) must consist of five elements and one attribute. These elements must be called name, street, city, state and zip as specified by the values of the declarations' name attributes, and the elements must appear in the same sequence (order) in which they are declared. The first four of these elements will each contain a string, and the fifth will contain a number. The element whose type is declared to be USAddress may appear with an attribute called country which must contain the string US.

The USAddress definition contains only declarations involving the simple types: string, decimal and NMTOKEN. In contrast, the PurchaseOrderType definition contains element declarations involving complex types, e.g. USAddress, although note that both declarations use the same type attribute to identify the type, regardless of whether the type is simple or complex.

Example
Defining PurchaseOrderType
<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>
po.xml

In defining PurchaseOrderType, two of the element declarations, for shipTo and billTo, associate different element names with the same complex type, namely USAddress. The consequence of this definition is that any element appearing in an instance document (e.g. ) whose type is declared to be PurchaseOrderType must consist of elements named shipTo and billTo, each containing the five subelements (name, street, city, state and zip) that were declared as part of USAddress. The shipTo and billTo elements may also carry the country attribute that was declared as part of USAddress.

The PurchaseOrderType definition contains an orderDate attribute declaration which, like the country attribute declaration, identifies a simple type. In fact, all attribute declarations must reference simple types because, unlike element declarations, attributes cannot contain other elements or other attributes.

The element declarations we have described so far have each associated a name with an existing type definition. Sometimes it is preferable to use an existing element rather than declare a new element, for example:

Example
<xsd:element ref="comment" minOccurs="0"/>

This declaration references an existing element, comment, that was declared elsewhere in the purchase order schema. In general, the value of the ref attribute must reference a global element, i.e. one that has been declared under schema rather than as part of a complex type definition. The consequence of this declaration is that an element called comment may appear in an instance document, and its content must be consistent with that element's type, in this case, string.

2.2.1 Occurrence ConstraintsminOccurs

The comment element is optional within PurchaseOrderType because the value of the attribute in its declaration is 0. In general, an element is required to appear when the value of minOccurs is 1 or more. The maximum number of times an element may appear is determined by the value of a maxOccurs attribute in its declaration. This value may be a positive integer such as 41, or the term unbounded to indicate there is no maximum number of occurrences. The default value for both the minOccurs and the maxOccurs attributes is 1. Thus, when an element such as comment is declared without a maxOccurs attribute, the element may not occur more than once. Be sure that if you specify a value for only the minOccurs attribute, it is less than or equal to the default value of maxOccurs, i.e. it is 0 or 1. Similarly, if you specify a value for only the maxOccurs attribute, it must be greater than or equal to the default value of minOccurs, i.e. 1 or more. If both attributes are omitted, the element must appear exactly once.

Attributes may appear once or not at all, but no other number of times, and so the syntax for specifying occurrences of attributes is different than the syntax for elements. In particular, attributes can be declared with a use attribute to indicate whether the attribute is required (see for example, the partNum attribute declaration in po.xsd), optional, or even prohibited.

Default values of both attributes and elements are declared using the default attribute, although this attribute has a slightly different consequence in each case. When an attribute is declared with a default value, the value of the attribute is whatever value appears as the attribute's value in an instance document; if the attribute does not appear in the instance document, the schema processor provides the attribute with a value equal to that of the default attribute. Note that default values for attributes only make sense if the attributes themselves are optional, and so it is an error to specify both a default value and anything other than a value of optional for use.

The schema processor treats defaulted elements slightly differently. When an element is declared with a default value, the value of the element is whatever value appears as the element's content in the instance document; if the element appears without any content, the schema processor provides the element with a value equal to that of the default attribute. However, if the element does not appear in the instance document, the schema processor does not provide the element at all. In summary, the differences between element and attribute defaults can be stated as: Default attribute values apply when attributes are missing, and default element values apply when elements are empty.

The fixed attribute is used in both attribute and element declarations to ensure that the attributes and elements are set to particular values. For example, po.xsd contains a declaration for the country attribute, which is declared with a fixed value US. This declaration means that the appearance of a country attribute in an instance document is optional (the default value of use is optional), although if the attribute does appear, its value must be US, and if the attribute does not appear, the schema processor will provide a country attribute with the value US. Note that the concepts of a fixed value and a default value are mutually exclusive, and so it is an error for a declaration to contain both fixed and default attributes.

The values of the attributes used in element and attribute declarations to constrain their occurrences are summarized in Table 1.

Table 1. Occurrence Constraints for Elements and Attributes
Elements (minOccurs, maxOccurs) fixed, default
Attributes use, fixed, default
Notes (1, 1) -, - required, -, - element/attribute must appear once, it may have any value (1, 1) 37, - required, 37, - element/attribute must appear once, its value must be 37 (2, unbounded) 37, - n/a element must appear twice or more, its value must be 37; in general, minOccurs and maxOccurs values may be positive integers, and maxOccurs value may also be "unbounded" (0, 1) -, - optional, -, - element/attribute may appear once, it may have any value (0, 1) 37, - n/a element may appear once, if it does not appear it is not provided; if it does appear and it is empty, its value is 37; if it does appear and it is not empty, its value must be 37 n/a optional, 37, - attribute may appear once, if it does appear its value must be 37, if it does not appear its value is 37 (0, 1) -, 37 n/a element may appear once; if it does not appear it is not provided; if it does appear and it is empty, its value is 37; otherwise its value is that given n/a optional, -, 37 attribute may appear once; if it does not appear its value is 37, otherwise its value is that given (0, 2) -, 37 n/a element may appear once, twice, or not at all; if the element does not appear it is not provided; if it does appear and it is empty, its value is 37; otherwise its value is that given; in general, minOccurs and maxOccurs values may be positive integers, and maxOccurs value may also be "unbounded" (0, 0) -, - prohibited, -, - element/attribute must not appear Note that neither minOccurs, maxOccurs, nor use may appear in the declarations of global elements and attributes. 2.2.2 Global Elements & Attributesschema

Global elements, and global attributes, are created by declarations that appear as the children of the element. Once declared, a global element or a global attribute can be referenced in one or more declarations using the ref attribute as described above. A declaration that references a global element enables the referenced element to appear in the instance document in the context of the referencing declaration. So, for example, the comment element appears in po.xml at the same level as the shipTo, billTo and items elements because the declaration that references comment appears in the complex type definition at the same level as the declarations of the other three elements.

The declaration of a global element also enables the element to appear at the top-level of an instance document. Hence purchaseOrder, which is declared as a global element in po.xsd, can appear as the top-level element in po.xml. Note that this rationale will also allow a comment element to appear as the top-level element in a document like po.xml.

There are a number of caveats concerning the use of global elements and attributes. One caveat is that global declarations cannot contain references; global declarations must identify simple and complex types directly. Put concretely, global declarations cannot contain the ref attribute, they must use the type attribute (or, as we describe shortly, be followed by an anonymous type definition). A second caveat is that cardinality constraints cannot be placed on global declarations, although they can be placed on local declarations that reference global declarations. In other words, global declarations cannot contain the attributes minOccurs, maxOccurs, or use.

2.2.3 Naming Conflictsprevious sub-section next sub-section

We have now described how to define new complex types (e.g. PurchaseOrderType), declare elements (e.g. purchaseOrder) and declare attributes (e.g. orderDate). These activities generally involve naming, and so the question naturally arises: What happens if we give two things the same name? The answer depends upon the two things in question, although in general the more similar are the two things, the more likely there will be a conflict.

Here are some examples to illustrate when same names cause problems. If the two things are both types, say we define a complex type called USStates and a simple type called USStates, there is a conflict. If the two things are a type and an element or attribute, say we define a complex type called USAddress and we declare an element called USAddress, there is no conflict. If the two things are elements within different types (i.e. not global elements), say we declare one element called name as part of the USAddress type and a second element called name as part of the Item type, there is no conflict. (Such elements are sometimes called local element declarations.) Finally, if the two things are both types and you define one and XML Schema has defined the other, say you define a simple type called decimal, there is no conflict. The reason for the apparent contradiction in the last example is that the two types belong to different namespaces. We explore the use of namespaces in schema in a later section.

2.3 Simple TypesList Types
2.3.2 Union Types

2.3.1

The purchase order schema declares several elements and attributes that have simple types. Some of these simple types, such as string and decimal, are built in to XML Schema, while others are derived from the built-in's. For example, the partNum attribute has a type called SKU (Stock Keeping Unit) that is derived from string. Both built-in simple types and their derivations can be used in all element and attribute declarations. Table 2 lists all the simple types built in to XML Schema, along with examples of the different types.

Table 2. Simple Types Built In to XML Schema Simple Type Examples (delimited by commas) Notes
string Confirm this is electric
normalizedString Confirm this is electric see (3)
token Confirm this is electric see (4)
base64Binary GpM7
hexBinary 0FB7
integer ...-1, 0, 1, ... see (2)
positiveInteger 1, 2, ... see (2)
negativeInteger ... -2, -1 see (2)
nonNegativeInteger 0, 1, 2, ... see (2)
nonPositiveInteger ... -2, -1, 0 see (2)
long -9223372036854775808, ... -1, 0, 1, ... 9223372036854775807 see (2)
unsignedLong 0, 1, ... 18446744073709551615 see (2)
int -2147483648, ... -1, 0, 1, ... 2147483647 see (2)
unsignedInt 0, 1, ...4294967295 see (2)
short -32768, ... -1, 0, 1, ... 32767 see (2)
unsignedShort 0, 1, ... 65535 see (2)
byte -128, ...-1, 0, 1, ... 127 see (2)
unsignedByte 0, 1, ... 255 see (2)
decimal -1.23, 0, 123.4, 1000.00 see (2)
float -INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN equivalent to single-precision 32-bit floating point, NaN is "not a number", see (2)
double -INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN equivalent to double-precision 64-bit floating point, see (2)
boolean true, false, 1, 0
duration P1Y2M3DT10H30M12.3S 1 year, 2 months, 3 days, 10 hours, 30 minutes, and 12.3 seconds
dateTime 1999-05-31T13:20:00.000-05:00 May 31st 1999 at 1.20pm Eastern Standard Time which is 5 hours behind Co-Ordinated Universal Time, see (2)
date 1999-05-31 see (2)
time 13:20:00.000, 13:20:00.000-05:00 see (2)
gYear 1999 1999, see (2) (5)
gYearMonth 1999-02 the month of February 1999, regardless of the number of days, see (2) (5)
gMonth --05 May, see (2) (5)
gMonthDay --05-31 every May 31st, see (2) (5)
gDay ---31 the 31st day, see (2) (5)
Name shipTo XML 1.0 Name type
QName po:USAddress XML Namespace QName
NCName USAddress XML Namespace NCName, i.e. a QName without the prefix and colon
anyURI
http://www.example.com/,
http://www.example.com/doc.html#ID5
language en-GB, en-US, fr valid values for xml:lang as defined in XML 1.0
ID XML 1.0 ID attribute type, see (1)
IDREF XML 1.0 IDREF attribute type, see (1)
IDREFS XML 1.0 IDREFS attribute type, see (1)
ENTITY XML 1.0 ENTITY attribute type, see (1)
ENTITIES XML 1.0 ENTITIES attribute type, see (1)
NOTATION XML 1.0 NOTATION attribute type, see (1)
NMTOKEN
US,
Brésil
XML 1.0 NMTOKEN attribute type, see (1)
NMTOKENS
US UK,
Brésil Canada Mexique
XML 1.0 NMTOKENS attribute type, i.e. a whitespace separated list of NMTOKEN's, see (1)
Notes: (1) To retain compatibility between XML Schema and XML 1.0 DTDs, the simple types ID, IDREF, IDREFS, ENTITY, ENTITIES, NOTATION, NMTOKEN, NMTOKENS should only be used in attributes. (2) A value of this type can be represented by more than one lexical format, e.g. 100 and 1.0E2 are both valid float formats representing "one hundred". However, rules have been established for this type that define a canonical lexical format, see XML Schema Part 2. (3) Newline, tab and carriage-return characters in a normalizedString type are converted to space characters before schema processing. (4) As normalizedString, and adjacent space characters are collapsed to a single space character, and leading and trailing spaces are removed. (5) The "g" prefix signals time periods in the Gregorian calendar.

New simple types are defined by deriving them from existing simple types (built-in's and derived). In particular, we can derive a new simple type by restricting an existing simple type, in other words, the legal range of values for the new type are a subset of the existing type's range of values. We use the element to define and name the new simple type. We use the

restriction element to indicate the existing (base) type, and to identify the "facets" that constrain the range of values. A complete list of facets is provided in Appendix B.

Suppose we wish to create a new type of integer called myInteger whose range of values is between 10000 and 99999 (inclusive). We base our definition on the built-in simple type integer, whose range of values also includes integers less than 10000 and greater than 99999. To define myInteger, we restrict the range of the integer base type by employing two facets called minInclusive and maxInclusive:

Example
Defining myInteger, Range 10000-99999
<xsd:simpleType name="myInteger">
  <xsd:restriction base="xsd:integer">
    <xsd:minInclusive value="10000"/>
    <xsd:maxInclusive value="99999"/>
  </xsd:restriction>
</xsd:simpleType>
Appendix B) should suggest other viable combinations.

The example shows one particular combination of a base type and two facets used to define myInteger, but a look at the list of built-in simple types and their facets (

The purchase order schema contains another, more elaborate, example of a simple type definition. A new simple type called SKU is derived (by restriction) from the simple type <a hr

分享到：
| XML:xml日期时间型总结
评论
发表评论

您还没有登录,请您登录后再发表评论

相关推荐

    XML::Validator::Schema-开源

    XML::Validator::Schema 是一个基于 Perl 语言的开源模块，其主要功能是验证 XML 文档是否符合 W3C XML Schema 的规范。W3C XML Schema（通常简称为 XML Schema）是一种用于定义 XML 文档结构和数据类型的语言，它...

    理解XML Schema XML Schema进阶

    XML Schema是目前国际标准的XML建模工具，本文将对XML Schema进行详细的介绍，帮助读者初步掌握XML Schema的使用方法和XML Schema文档实例的具体语义。 1. 命名空间的使用 XML Schema中命名空间的使用是非常重要的...

    XML详解----Schema(精讲)

    XML_schema_详解 XML Schema是XML文档的约束机制，用于定义XML文档的结构和内容。它是XML 1.0规范的一部分，提供了一个强大的工具来描述和验证XML文档。 XML Schema的优点是： * 强大的描述能力：XML Schema可以...

    XML Schema教程

    ### XML Schema 教程知识点详解 #### 一、XML Schema 概述 - **XML Schema 定义**：XML Schema 是一种基于 XML 的语言，用于描述 XML 文档的结构。它定义了 XML 文档中可以出现的元素、属性及其结构，并且指定了...

    根据xml schema生成xml

    这篇博客文章“根据XML Schema生成XML”探讨了如何使用XML Schema来创建符合规范的XML文档。 首先，理解XML Schema的基本元素是关键。XML Schema定义了一系列的元素（element）、属性（attribute）和数据类型（data...

    Schema教程 xml

    XML Schema教程 XML Schema是一种基于XML的文档类型定义（DTD）替代方案，它提供了更为强大且灵活的方式来描述XML文档的结构和数据类型。XML Schema定义（XSD）使用XML语法，使得XML文档的验证和处理更加方便。在这...

    XML与XMLSchema

    【XML与XMLSchema】 XML，全称可扩展标记语言（eXtensible Markup Language），是一种基于标准通用标记语言SGML的简化版本，由万维网联盟（W3C）于1996年开始制定，并在1998年2月10日发布了XML 1.0规范。它的设计...

    xmlschema-core-2.1.0-API文档-中文版.zip

    赠送jar包：xmlschema-core-2.1.0.jar； 赠送原API文档：xmlschema-core-2.1.0-javadoc.jar； 赠送源代码：xmlschema-core-2.1.0-sources.jar； 赠送Maven依赖信息文件：xmlschema-core-2.1.0.pom； 包含翻译后的API...

    xmlschema实验及答案.doc

    XML Schema实验及答案 XML Schema是基于XML的_schema语言，是一种用于定义XML文档结构的语言。它是W3C制定的一个标准，用于描述XML文档的结构、约束和关系。XML Schema提供了一个强大的工具，用于定义和验证XML文档...

    XML文件XML Schema.docXML Schema.doc

    "XML Schema知识点" XML Schema是XML语言为基础的，它用于可替代DTD。它用于描述XML文档的结构。XML Schema语言也被称为XML Schema Definition（XSD）。XML Schema的作用是定义一份XML文档的合法组件群，就像DTD的...

    XML Schema xsd XML Schema xsd

    XML Schema 是一种基于 XML 的规范，用于定义 XML 文档的结构和数据类型。它是 Document Type Definition (DTD) 的现代替代品，提供了更多功能和灵活性。XML Schema 的主要目标是为 XML 文档提供一种严格的形式化...

    运用XML Spy新建XML Schema的教程

    压缩包里详细介绍了如何利用XML Spy这个软件新建一个XML Schema文档，内容非常充实，在网上找了很久自己整理好的，只要按照文档的步骤就可以很快学会如何使用XML Spy了，非常适合初次接触XML知识和XML Spy这个软件的...

    XML、DTD、Schema

    XML Schema使用XML语法来定义XML文档的结构和数据类型，这意味着它能够表达更复杂的约束，如数据类型限制、命名空间支持和默认值设定。例如，一个XML Schema声明可能如下： ```xml &lt;xs:schema xmlns:xs=...

    XML文档约束之Schema

    XML Schema是XML的一种标准化约束机制，用于定义XML文档的结构和数据类型，确保数据的准确性和一致性。 XML Schema提供了比早期的DTD（Document Type Definition）更强大的功能，例如支持复杂数据类型、命名空间和...

    XMLSchema.chm

    XML Schema，简称为XSD，是XML（可扩展标记语言）的一个重要组成部分，用于定义XML文档的结构和数据类型。这个“XMLSchema.chm”文件很可能是一个帮助文档，旨在为学习XML Schema的用户提供详细的指导和参考资料。...

    apache xmlschema api文档

    Apache XML Schema API是Java开发人员用来处理XML Schema的工具包，它是Apache Xerces项目的一部分。XML Schema（通常缩写为XSD）是一种W3C标准，用于定义XML文档的结构和数据类型，确保XML数据的准确性和一致性。...

    xmlschema-core-2.2.1.jar

    如果是maven依赖，可以在pom.xml中引入以下配置 &lt;groupId&gt;org.apache.ws.xmlschema &lt;artifactId&gt;xmlschema-core &lt;version&gt;2.2.1 &lt;/dependency&gt;

    XSD根据xml生成schema文件

    XSD（XML Schema Definition）则是用来定义XML文档结构和数据类型的规范，它为XML提供了严格的语法规则，确保了数据的一致性和有效性。本篇文章将深入探讨如何根据XML文件生成对应的XSD schema文件，以便更好地管理...

    xml Schema学习

    XML Schema是一种用于定义XML文档结构和数据类型的规范，它是W3C（World Wide Web Consortium）在2001年发布的一个标准，旨在替代之前的DTD（Document Type Definition）。本篇文章将深入探讨XML Schema的学习要点，...

Magicbox
Global site tag (gtag.js) - Google Analytics