XML Schema 1.0 Specification Errata

E0-30 Editorial

See R-59, "Suggested changes for Appendix C of Primer", and E0-27.

§Appendix C Using Entities

Revise the third line of the first example as follows:

<!ENTITY eacute "↓é↓↑&#xE9;↑"/>

E0-29 Editorial

See R-43, "Imprecise text in Table 1 of Primer".

Table 1

Change Table 1 as follows:

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↑
↓(0, 1) 37, -↓↑n/a↑	optional, 37, -	↓element/↓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↑
↓(0, 1) -, 37↓↑n/a↑	optional, -, 37	↓element/↓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.

E0-28 Editorial

See R-44, "Grammatical errors in section 5.6 of the Primer".

§5.6 schemaLocation

Remove the first sentence of the third paragraph:

↓The schemaLocation attribute contains pairs of values: The first member of each pair is the namespace for which the second member is the hint describing where to find to an appropriate schema document.↓

and replace with:

↑The schemaLocation attribute value consists of one or more pairs of URI references, separated by white space. The first member of each pair is a namespace name, and the second member of the pair is a hint describing where to find an appropriate schema document for that namespace.↑

E0-27 Editorial

See R-59, "Suggested changes for Appendix C of Primer".

§Appendix C Using Entities

Note that E0-30 makes a further change to this example.

Revise the second sentence of the third paragraph as follows:

Note that when this instance document is processed, the entity will be ↓dereferenced↓↑resolved↑ before schema validation takes place.

Revise the the second example as follows:

<xsd:element name="eacute" type="xsd:token" fixed="↓é↓↑&#xE9;↑"/>

E0-26 Error

See R-81, "Error in Primer example of identity constraints".

§5.1 Specifying Uniqueness

Change the second and third paragraphs as follows:

We can also indicate combinations of fields that must be unique. ↓To illustrate, suppose we can relax the constraint that zip codes may only be listed once, although we still want to enforce the constraint that any product is listed only once within a given zip code. We could achieve such a constraint by specifying that the combination of zip code and product number must be unique. From the report document, 4Q99.xml, the combined values of zip code and number would be: {95819 872-AA}, {95819 926-AA}, {95819 833-AA}, {95819 455-BX}, and {63143 455-BX}. Clearly, these combinations do not distinguish between zip code and number combinations derived from single or multiple listings of any particular zip, but the combinations would unambiguously represent a product listed more than once within a single zip. In other words, a schema processor could detect violations of the uniqueness constraint.↓↑Going back to our purchase order example, suppose we want each item to have a unique combination of part number and product name. We could achieve such a constraint by specifying that for each item element, the combined values of its partNum attribute and its productName child must be unique.↑

To define combinations of values, we simply ↓add↓↑use multiple↑ field elements to identify all the values involved↓. So, to add the part number value to our existing definition, we add a new field element whose xpath attribute value, r:part/@number, identifies the number attribute of part elements that are children of the zip elements identified by r:regions/r:zip↓:

Replace the example:

A Unique Composed Value

↓ <unique name="dummy1">
  <selector xpath="r:regions/r:zip"/>
  <field    xpath="@code"/>
  <field    xpath="r:part/@number"/>
 </unique>↓

↑<xsd:element name="items" type="Items">
 <xsd:unique name="partNumAndName">
  <xsd:selector xpath="item"/>
  <xsd:field    xpath="@partNum"/>
  <xsd:field    xpath="productName"/>
 </xsd:unique>
</xsd:element>↑

E0-25 Error

See R-121, "Import example in section 5.4 of Primer incorrect".

§5.4 Importing Types

Change the fourth paragraph as follows:

Note however, that we cannot reuse the shipTo element from ↓po.xsd↓↑ipo.xsd↑, and the following is not legal because only global schema components can be imported:

Change the last sentence of the sixth paragraph as follows:

We can reuse the (globally defined) complex type USAddress from address.xsd, and extend it to define a new type called Analyst↑ in the report schema↑ by adding the new elements phone and email:

Change the fourth example as follows:

<↑r:↑purchaseReport
  xmlns↑:r↑="http://www.example.com/Report"
  period="P3M" periodEnding="1999-12-31">
  <!-- regions and parts elements omitted -->
   <↑r:↑analyst>
        <name>Wendy Uhro</name>
        <street>10 Corporate Towers</street>
        <city>San Jose</city>
        <state>CA</state>
        <zip>95113</zip>
        <↑r:↑phone>408-271-3366</↑r:↑phone>
        <↑r:↑email>uhro@example.com</↑r:↑email>
   </↑r:↑analyst>
</↑r:↑purchaseReport>

Add the following paragraph directly after the example:

↑Note that the report now has both qualified and unqualified elements. This is because some of the elements (name, street, city, state and zip) are locally declared in ipo.xsd, whose elementFormDefault is unqualified (by default). The other elements in the example are declared in report.xsd, whose elementFormDefault is set to qualified. ↑

E0-24 Editorial

See R-126, "Suggested change for the Primer re: substitution group members".

§4.6 Substitution Groups

Change the second sentence of the first paragraph as follows:

More specifically, elements can be assigned to a special group of elements that are said to be substitutable for a particular named element called the head element. (Note that the head element↑ as well as the substitutable elements↑ must be declared as ↓a ↓global element↑s↑.)

E0-23 Clarification

See R-104, "Primer question re: integer and the fractionDigits facet".

Table B1.a

Change Table B1.a as follows:

Table B1.a. Simple Types & Applicable Facets
Simple Types	Facets
	length	minLength	maxLength	pattern	enumeration	whiteSpace
string	y	y	y	y	y	y
normalizedString	y	y	y	y	y	y
token	y	y	y	y	y	↓y↓↑see (1)↑
byte				y	y	↓y↓↑see (1)↑
unsignedByte				y	y	↓y↓↑see (1)↑
base64Binary	y	y	y	y	y	↓y↓↑see (1)↑
hexBinary	y	y	y	y	y	↓y↓↑see (1)↑
integer				y	y	↓y↓↑see (1)↑
positiveInteger				y	y	↓y↓↑see (1)↑
negativeInteger				y	y	↓y↓↑see (1)↑
nonNegativeInteger				y	y	↓y↓↑see (1)↑
nonPositiveInteger				y	y	↓y↓↑see (1)↑
int				y	y	↓y↓↑see (1)↑
unsignedInt				y	y	↓y↓↑see (1)↑
long				y	y	↓y↓↑see (1)↑
unsignedLong				y	y	↓y↓↑see (1)↑
short				y	y	↓y↓↑see (1)↑
unsignedShort				y	y	↓y↓↑see (1)↑
decimal				y	y	↓y↓↑see (1)↑
float				y	y	↓y↓↑see (1)↑
double				y	y	↓y↓↑see (1)↑
boolean				y		↓y↓↑see (1)↑
time				y	y	↓y↓↑see (1)↑
dateTime				y	y	↓y↓↑see (1)↑
duration				y	y	↓y↓↑see (1)↑
date				y	y	↓y↓↑see (1)↑
gMonth				y	y	↓y↓↑see (1)↑
gYear				y	y	↓y↓↑see (1)↑
gYearMonth				y	y	↓y↓↑see (1)↑
gDay				y	y	↓y↓↑see (1)↑
gMonthDay				y	y	↓y↓↑see (1)↑
Name	y	y	y	y	y	↓y↓↑see (1)↑
QName	y	y	y	y	y	↓y↓↑see (1)↑
NCName	y	y	y	y	y	↓y↓↑see (1)↑
anyURI	y	y	y	y	y	↓y↓↑see (1)↑
language	y	y	y	y	y	↓y↓↑see (1)↑
ID	y	y	y	y	y	↓y↓↑see (1)↑
IDREF	y	y	y	y	y	↓y↓↑see (1)↑
IDREFS	y	y	y		y	↓y↓↑see (1)↑
ENTITY	y	y	y	y	y	↓y↓↑see (1)↑
ENTITIES	y	y	y		y	↓y↓↑see (1)↑
NOTATION	y	y	y	y	y	↓y↓↑see (1)↑
NMTOKEN	y	y	y	y	y	↓y↓↑see (1)↑
NMTOKENS	y	y	y		y	↓y↓↑see (1)↑
↑ Note: (1) Although the whiteSpace facet is applicable to this type, the only value that can be specified is collapse.↑

Change Table B1.b as follows:

Table B1.b. Simple Types & Applicable Facets
Simple Types	Facets
	max Inclusive	max Exclusive	min Inclusive	min Exclusive	totalDigits	fractionDigits
byte	y	y	y	y	y	↓y↓↑see (1)↑
unsignedByte	y	y	y	y	y	↓y↓↑see (1)↑
integer	y	y	y	y	y	↓y↓↑see (1)↑
positiveInteger	y	y	y	y	y	↓y↓↑see (1)↑
negativeInteger	y	y	y	y	y	↓y↓↑see (1)↑
nonNegativeInteger	y	y	y	y	y	↓y↓↑see (1)↑
nonPositiveInteger	y	y	y	y	y	↓y↓↑see (1)↑
int	y	y	y	y	y	↓y↓↑see (1)↑
unsignedInt	y	y	y	y	y	↓y↓↑see (1)↑
long	y	y	y	y	y	↓y↓↑see (1)↑
unsignedLong	y	y	y	y	y	↓y↓↑see (1)↑
short	y	y	y	y	y	↓y↓↑see (1)↑
unsignedShort	y	y	y	y	y	↓y↓↑see (1)↑
decimal	y	y	y	y	y	y
float	y	y	y	y
double	y	y	y	y
time	y	y	y	y
dateTime	y	y	y	y
duration	y	y	y	y
date	y	y	y	y
gMonth	y	y	y	y
gYear	y	y	y	y
gYearMonth	y	y	y	y
gDay	y	y	y	y
gMonthDay	y	y	y	y
↑ Note: (1) Although the fractionDigits facet is applicable to this type, the only value that can be specified is zero.↑

E0-22 Error

See R-33, "Request for clarification of identity constraint rules".

report.xsd, in §5 Advanced Concepts III: The Quarterly Report

Revise report.xsd shown:

<schema targetNamespace="http://www.example.com/Report"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:r="http://www.example.com/Report"
        xmlns:xipo="http://www.example.com/IPO"
        elementFormDefault="qualified">

 <!-- for SKU -->
 <import namespace="http://www.example.com/IPO"/>

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

 <element name="purchaseReport">
  <complexType>
   <sequence>
    <element name="regions" type="r:RegionsType"↑/↑>
     ↓<keyref name="dummy2" refer="r:pNumKey">
      <selector xpath="r:zip/r:part"/>
      <field xpath="@number"/>
     </keyref>
    </element>↓

    <element name="parts" type="r:PartsType"/>
   </sequence>
   <attribute name="period"       type="duration"/>
   <attribute name="periodEnding" type="date"/>
  </complexType>

  <unique name="dummy1">
   <selector xpath="r:regions/r:zip"/>
   <field xpath="@code"/>
  </unique>

  <key name="pNumKey">
   <selector xpath="r:parts/r:part"/>
   <field xpath="@number"/>
  </key>

  ↑<keyref name="dummy2" refer="r:pNumKey">
   <selector xpath="r:regions/r:zip/r:part"/>
   <field xpath="@number"/>
  </keyref>↑

 </element>

 ...

</schema>

Section 5.2

Change the first sentence of the second paragraph, as amended by E0-7, as follows:

To ensure that the part-quantity elements have corresponding part descriptions, we say that the number attribute ( <field xpath="@number"/>) of those elements (<selector xpath="↑r:regions/↑r:zip/r:part"/>) must reference the pNumKey key.

E0-21 Clarification

See R-3, "Primer states that all components must be repeated in restriction", and R-67, "A question about type derivation and anonymous types".

§4.4 Deriving Complex Types by Restriction

Change the second paragraph as follows:

For example, suppose we want to update our definition of ↓ the list of items in an international↓↑a↑ purchase order so that it must contain ↓at least one item on order↓↑a comment↑; the schema shown in ipo.xsd allows a↓n items↓↑ purchaseOrder↑ element to appear without any child ↓item↓ ↑comment↑ elements. To create our new ↓ConfirmedItems↓ ↑RestrictedPurchaseOrderType↑ type, we define the new type in the usual way, indicate that it is derived by restriction from the base type ↓ Items↓ ↑PurchaseOrderType↑ , and provide a new (more restrictive) value for the minimum number of ↓item↓ ↑comment↑ element occurrences. Notice that types derived by restriction must repeat all the ↑particle↑ components↑ (element declarations, model groups, and wildcards)↑ of the base type definition that are to be included in the derived type↓:↓↑. However, attribute declarations do not need to be repeated in the derived type definition; in this example, RestrictedPurchaseOrderType will inherit the orderDate attribute declaration from PurchaseOrderType.↑

Replace the example as shown:

↓

Deriving ConfirmedItems by Restriction from Items

<complexType name="ConfirmedItems">
 <complexContent>
  <restriction base="ipo:Items">
   <sequence>

    <!-- item element is different than in Items -->
    <element name="item" minOccurs="1" maxOccurs="unbounded">

     <!-- remainder of definition is same as Items -->
     <complexType>
      <sequence>
       <element name="productName" type="string"/>
       <element name="quantity">
        <simpleType>
         <restriction base="positiveInteger">
          <maxExclusive value="100"/>
         </restriction>
        </simpleType>
       </element>
       <element name="USPrice"    type="decimal"/>
       <element ref="ipo:comment" minOccurs="0"/>
       <element name="shipDate"   type="date" minOccurs="0"/>
      </sequence>
      <attribute name="partNum" type="ipo:SKU" use="required"/>
     </complexType>
    </element>

   </sequence>
  </restriction>
 </complexContent>
</complexType>

↓

↑

Deriving RestrictedPurchaseOrderType by Restriction from PurchaseOrderType

<complexType name="RestrictedPurchaseOrderType">
 <complexContent>
  <restriction base="ipo:PurchaseOrderType">
   <sequence>
    <element name="shipTo" type="ipo:Address"/>
    <element name="billTo" type="ipo:Address"/>
    <element ref="ipo:comment" minOccurs="1"/>
    <element name="items"  type="ipo:Items"/>
   </sequence>
  </restriction>
 </complexContent>
</complexType>

↑

Change the third paragraph as follows:

This change↓, requiring at least one child element rather than allowing zero or more child elements,↓ narrows the allowable number of ↓child↓↑comment↑ elements from a minimum of 0 to a minimum of 1. Note that all ↓ConfirmedItems↓↑RestrictedPurchaseOrderType↑ type elements will also be acceptable as ↓Item↓↑PurchaseOrderType↑ type elements.

E0-20 Editorial

See R-6, "Confusing table in the Primer".

Table 3, in §4.4 Deriving Complex Types by Restriction

Change Table 3 as follows (including adding line breaks between values in column 2):

Table 3. Restriction Examples
Base	Restriction↑(s)↑	Notes
	default="1"	setting a default value where none was previously given
	fixed="100"	setting a fixed value where none was previously given
	type="string"	specifying a type where none was previously given
(minOccurs, maxOccurs)	(minOccurs, maxOccurs)
(0, 1)	(0, 0)	exclusion of an optional component; this may also be accomplished by omitting the component's declaration from the restricted type definition
↑(0, 1)↑	↑(1, 1)↑	↑making an optional component required↑
(0, unbounded)	(0, 0)↑ ↑ (0, 37)↑ ↑(1, 37)
(1, 9)	(1, 8)↑ ↑ (2, 9)↑ ↑ (4, 7)↑ ↑ (3, 3)
(1, unbounded)	(1, 12)↑ ↑ (3, unbounded)↑ ↑ (6, 6)
(1, 1)	↑(1, 1)↑	cannot ↑further ↑restrict minOccurs or maxOccurs

E0-19 Editorial

See R-5, "Typographical error in section 2.8 example".

§2.8 Attribute Groups

Change the first line of the first example as follows:

<xsd:element name="↓Item↓↑item↑" minOccurs="0" maxOccurs="unbounded">

E0-18 Clarification

See R-18, "Use of pattern facet for list type".

Table B1.a

Change Table B1.a as follows:

Table B1.a. Simple Types & Applicable Facets
Simple Types	Facets
	length	minLength	maxLength	pattern	enumeration	whiteSpace
IDREFS	y	y	y	↑y↑	y	y
ENTITIES	y	y	y	↑y↑	y	y
NMTOKENS	y	y	y	↑y↑	y	y

E0-17 Editorial

See R-36, "Font of text in section 2.5.2 of Primer incorrect".

§2.5.2 Mixed Content

Change the font of the word "name" in the second sentence of the third paragraph as follows:

Notice the text appearing between elements and their child elements. Specifically, text appears between the elements salutation, quantity, productName and shipDate which are all children of letterBody, and text appears around the element ↓name↓↑name↑ which is the child of a child of letterBody.

E0-16 Editorial

See R-45, "Inaccurate language in section 5.5 of Primer re: references to HTML".

§5.5 Any Element, Any Attribute

Revise the second paragraph as follows:

To illustrate, consider a version of the quarterly report, 4Q99html.xml, in which we have embedded an ↑X↑HTML representation of the XML parts data. The ↑X↑HTML content appears as the content of the element htmlExample, and the default namespace is changed on the outermost ↑X↑HTML element (table) so that all the ↑X↑HTML elements belong to the ↑X↑HTML namespace, http://www.w3.org/1999/xhtml:

Revise the first example header as follows:

Quarterly Report with ↑X↑HTML, 4Q99html.xml

Revise the third paragraph as follows:

To permit the appearance of ↑X↑HTML in the instance document we modify the report schema by declaring a new element htmlExample whose content is defined by the any element. In general, an any element specifies that any well-formed XML is permissible in a type's content model. In the example, we require the XML to belong to the namespace http://www.w3.org/1999/xhtml, in other words, it should be ↑X↑HTML. The example also requires there to be at least one element present from this namespace, as indicated by the values of minOccurs and maxOccurs:

Revise the second example header as follows:

Modification to purchaseReport Declaration to Allow ↑X↑HTML in Instance

Revise the fourth paragraph as follows:

The modification permits some well-formed XML belonging to the namespace http://www.w3.org/1999/xhtml to appear inside the htmlExample element. Therefore 4Q99html.xml is permissible because there is one element which (with its children) is well-formed, the element appears inside the appropriate element (htmlExample), and the instance document asserts that the element and its content belongs to the required namespace. However, the ↑X↑HTML may not actually be valid because nothing in 4Q99html.xml by itself can provide that guarantee. If such a guarantee is required, the value of the processContents attribute should be set to strict (the default value). In this case, an XML processor is obliged to obtain the schema associated with the required namespace, and validate the ↑X↑HTML appearing within the htmlExample element.

Revise the seventh paragraph as follows:

In addition to the any element which enables element content according to namespaces, there is a corresponding anyAttribute element which enables attributes to appear in elements. For example, we can permit any ↑X↑HTML attribute to appear as part of the htmlExample element by adding anyAttribute to its declaration:

Revise the fourth example header as follows:

Modification to htmlExample Declaration to Allow ↑X↑HTML Attributes

Revise the eigth paragraph as follows:

This declaration permits an ↑X↑HTML attribute, say href, to appear in the htmlExample element. For example:

Revise the fifth example as follows:

Example

An ↑X↑HTML attribute in the htmlExample Element

....
  <htmlExample xmlns:h="http://www.w3.org/1999/xhtml"
               h:href="http://www.example.com/reports/4Q99.html">
    <!-- ↑X↑HTML markup here -->
  </htmlExample>
....

§5.6 schemaLocation

Change the final paragraph as follows:

Note that the schemaLocation is only a hint and some processors and applications will have reasons to not use it. For example, an ↑X↑HTML editor may have a built-in ↑X↑HTML schema.

E0-15 Error

See R-48, "Lexical representation of gMonth is inconsistent wrt ISO 8601".

Table 2, in §2.3 Simple Types

Remove trailing hyphens from the gMonth example as follows:

Table 2. Simple Types Built In to XML Schema
Simple Type	Examples (delimited by commas)	Notes
gMonth	--05↓--↓	May, see (2) (5)

E0-14 Error

See R-50, "'appInfo' element in Primer vs. 'appinfo' element in Structures".

§2.6 Annotations

Correct the capitalization of appinfo in the second paragraph and third paragraphs as follows:

The ↓appInfo↓↑appinfo↑ element, which we did not use in the purchase order schema, can be used to provide information for tools, stylesheets and other applications. An interesting example using ↓appInfo↓↑appinfo↑ is a schema that describes the simple types in XML Schema Part 2: Datatypes. Information describing this schema, e.g. which facets are applicable to particular simple types, is represented inside ↓appInfo↓↑appinfo↑ elements, and this information was used by an application to automatically generate text for the XML Schema Part 2 document.

Both documentation and ↓appInfo↓↑appinfo↑ appear as subelements of annotation, which may itself appear at the beginning of most schema constructions. To illustrate, the following example shows annotation elements appearing at the beginning of an element declaration and a complex type definition:

§Appendix E Index

Change the list in Appendix E as follows:

↓appInfo↓↑appinfo↑: 2.6

E0-13 Editorial

See R-55, "Typo in table 2 of the Primer".

Table 2, in §2.3 Simple Types

Change Table 2 as follows:

Table 2. Simple Types Built In to XML Schema
Simple Type	Examples (delimited by commas)	Notes
byte	↓-1, 126↓↑-128, ...-1, 0, 1, ... 127↑	see (2)
unsignedByte	↓0, 126↓↑0, 1, ... 255↑	see (2)
integer	↓-126789, -1, 0, 1, 126789↓↑...-1, 0, 1, ...↑	see (2)
positiveInteger	↓1, 126789↓↑1, 2, ...↑	see (2)
negativeInteger	↓-126789, -1↓↑... -2, -1↑	see (2)
nonNegativeInteger	↓0, 1, 126789↓↑0, 1, 2, ...↑	see (2)
nonPositiveInteger	↓-126789, -1, 0↓↑... -2, -1, 0↑	see (2)
int	↓-1, 126789675↓↑-2147483648, ... -1, 0, 1, ... 2147483647↑	see (2)
unsignedInt	↓0, 1267896754↓↑0, 1, ...4294967295↑	see (2)
long	↓-1, 12678967543233↓↑-9223372036854775808, ... -1, 0, 1, ... 9223372036854775807↑	see (2)
unsignedLong	↓0, 12678967543233↓↑0, 1, ... 18446744073709551615↑	see (2)
short	↓-1, 12678↓↑-32768, ... -1, 0, 1, ... 32767↑	see (2)
unsignedShort	↓0, 12678↓↑0, 1, ... 65535↑	see (2)

E0-12 Editorial

See R-58, "Errors in example in Appendix C of Primer".

§Appendix C Using Entities

Change the first example as follows:

<?xml version="1.0" ?>
<!DOCTYPE ↑p↑↓P↓urchaseOrder [
<!ENTITY eacute "é">
]>
<purchaseOrder xmlns="http://www.example.com/PO1"
               orderDate="1999-10-20↑"↑>
 <!-- etc. -->
  <city>Montr&eacute;al</city>
 <!-- etc. -->
</purchaseOrder>

E0-11 Error

See R-69, "Problem in the regex grammar for charRange".

Table D1

Revise Table D1 as follows:

Table D1. Examples of Regular Expressions
Expression	Match(es)
[↑\↑-ae]x	-x, ax, ex
[ae↑\↑-]x	ax, ex, -x

E0-10 Error

See R-80, "Meaning of ##other".

Table 4, in §5.5 Any Element, Any Attribute

Change Table 4 as follows:

Table 4. Namespace Attribute in Any
Value of Namespace Attribute	Allowable Element Content
##other	Any well-formed XML that is ↑from a namespace other than↑↓not from↓ the target namespace of the type being defined ↑(unqualified elements are not allowed)↑

E0-9 Editorial

See R-82, "Three editorial errors in the Primer".

§2.3.1 List Types

Change the first sentence of the fourth paragraph as follows:

Several facets can be applied to list types: length, minLength, maxLength,↑ pattern,↑ and enumeration.

E0-8 Editorial

See R-82, "Three editorial errors in the Primer".

§5.1 Specifying Uniqueness

Change the third sentence of the first paragraph as follows:

In the case of our report schema, report.xsd, the selector element's xpath attribute contains an XPath expression, ↑r:↑regions/↑r:↑zip, that selects a list of all the zip elements in a report instance.

Change the second sentence of the third paragraph as follows:

So, to add the part number value to our existing definition, we add a new field element whose xpath attribute value, ↑r:↑part/@number, identifies the number attribute of part elements that are children of the zip elements identified by ↑r:↑regions/↑r:↑zip:

E0-7 Editorial

See R-82, "Three editorial errors in the Primer".

§5.2 Defining Keys and their References

Change the second paragraph as follows:

To ensure that the part-quantity elements have corresponding part descriptions, we say that the number attribute ( ↓<field>@number</field>↓↑<field xpath="@number"/>↑) of those elements (↓<selector>zip/part</selector>↓↑<selector xpath="r:zip/r:part"/>↑) must reference the pNumKey key. This declaration of number as a keyref does not mean that its value must be unique, but it does mean there must exist a pNumKey with the same value.

E0-6 Editorial

See R-155, "4 Typos in the Primer".

§2.4 Anonymous Type Definitions

Revise the last sentence of the section as follows:

In the case of the quantity element, it has an anonymous simple type derived from ↓integer↓↑positiveInteger↑ whose value ranges between 1 and 99.

E0-5 Editorial

See R-155, "4 Typos in the Primer".

Table 2, in §2.3 Simple Types

Revise the last note at the end of Table 2 as follows:

(5) The "g" prefix signals time periods in the Gregorian ↓calender↓↑calendar↑.

E0-4 Editorial

See R-155, "4 Typos in the Primer".

§4.2 Deriving Types by Extension

Revise the last sentence in the first paragraph as follows:

The technique we use here to derive new (complex) address types by extending an existing type is the same technique we used in ↓in ↓Section 2.5.1....

E0-3 Editorial

See R-155, "4 Typos in the Primer".

Table D1, in §Appendix D Regular Expressions

Revise Table D1 as follows:

Table D1. Examples of Regular Expressions
Expression	Match(es)
Espa↓n↓ñola	Española

E0-2 Editorial

See R-4, "Conflicting statements about Primer being normative/non-normative".

Status of this Document

Change the second sentence of the second paragraph as follows:

It is a stable document and may be used as reference material ↓ or cited as a normative reference from another document ↓.

E0-1 Editorial

See R-2, "Primer states that there are 15 facets".

§2.3 Simple Types: Description of Facets, next-to-last paragraph before §2.3.1

Change the first sentence as follows:

XML Schema defines ↓ fifteen ↓ ↑ twelve ↑ facets which are listed in Appendix B.

E1-55 Error

(No issues list entry for this one yet)

Note that the text below also shows the change mandated by E1-30.

In §3.4.2 XML Representation of Complex Type Definitions, in the simple content case of the property mapping tableau for Complex Type Definitions, add clause 3.2.2.2 as follows (note that in addition to the highlighted change, the existing sub-clauses of clause 3.2 have been renumbered and restructured):

3.2 If the <extension> alternative is chosen, then

3.2.1 [Definition:]  let the base wildcard be defined as the appropriate case among the following:

3.2.1.1 If the type definition ·resolved· to by the ·actual value· of the base [attribute] is a complex type definition with an {attribute wildcard}, then that {attribute wildcard}.

3.2.1.2 otherwise ·absent·.

3.2.2 The value is then determined by the appropriate case among the following:

3.2.2.1 If the ·base wildcard· is non-·absent·, then the appropriate case among the following:

3.2.2.1.1 If the ·complete wildcard· is ·absent·, then the ·base wildcard·.

3.2.2.1.2 otherwise a wildcard whose {process contents} and {annotation} are those of the ·complete wildcard·, and whose {namespace constraint} is the intensional union of the {namespace constraint} of the ↓·effective wildcard·↓↑·complete wildcard·↑ and of the ·base wildcard·, as defined in Attribute Wildcard Union (§3.10.6).

↑

3.2.2.2 otherwise (the ·base wildcard· is ·absent·) the ·complete wildcard·

↑

E1-54 Error

See R-67 pfiTypeDerivation, "A question about type derivation and anonymous types". This change supersedes E1-17.

In §3.4.6 Constraints on Complex Type Definition Schema Components, add the following after the (now unchanged) Schema Component Constraint: Type Derivation OK (Complex):

↑

Note:

The wording of clause 2.1 above appeals to a notion of component identity which is only incompletely defined by this version of this specification. In some cases, the wording of this specification does make clear the rules for component identity. These cases include:

• When they are both top-level components with the same component type, namespace name, and local name;
• When they are necessarily the same type definition (for example, when the two types definitions in question are the type definitions associated with two attribute or element declarations, which are discovered to be the same declaration);
• When they are the same by construction (for example, when an element's type definition defaults to being the same type definition as that of its substitution-group head or when a complex type definition inherits an attribute declaration from its base type definition).

In other cases two conforming implementations may disagree as to whether components are identical.

↑

Also, in §3.14.6 Constraints on Simple Type Definition Schema Components, change Schema Component Constraint: Type Derivation OK (Simple) as follows:

Schema Component Constraint: Type Derivation OK (Simple)

For a simple type definition (call it D, for derived) to be validly derived from a ↓simple ↓type definition (call this B, for base) given a subset of {extension, restriction, list, union} (of which only restriction is actually relevant) one of the following must be true:

1 They are the same type definition.

2 All of the following must be true:

2.1 restriction is not in the subset, or in the {final} of its own {base type definition};

2.2 One of the following must be true:

2.2.1 D's ·base type definition· is B.

2.2.2 D's ·base type definition· is not the ·↓simple ↓ur-type definition· and is validly derived from B given the subset, as defined by this constraint.

2.2.3 D's {variety} is list or union and B is the ·simple ur-type definition·.

2.2.4 B's {variety} is union and D is validly derived from a type definition in B's {member type definitions} given the subset, as defined by this constraint.

Also, in §3.14.6 Constraints on Simple Type Definition Schema Components, add the following after Schema Component Constraint: Type Derivation OK (Simple) :

↑

Note: With respect to clause 1, see the Note on identity at the end of (§3.4.6) above.

↑

E1-53 Error

See R-8 pfiFinalDefault, "Should finalDefault allow list, union?".

In §Appendix A Schema for Schemas (normative), change to the element declaration for 'schema', as follows:

  <xs:element name="schema" id="schema">
     . . .
     <xs:complexType>
       . . .
          <xs:attribute name="finalDefault" ↓type="xs:derivationSet"↓ ↑type="xs:fullDerivationSet"↑
                        default="" use="optional"/>
     </xs:complexType>
     . . .
  </xs:element>

Also, in §Appendix A Schema for Schemas (normative), add the following:

  ↑<xs:simpleType name="typeDerivationControl">
    <xs:annotation>
      <xs:documentation>
   A utility type, not for public use</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:derivationControl">
      <xs:enumeration value="extension"/>
      <xs:enumeration value="restriction"/>
      <xs:enumeration value="list"/>
      <xs:enumeration value="union"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="fullDerivationSet">
    <xs:annotation>
      <xs:documentation>
   A utility type, not for public use</xs:documentation>
      <xs:documentation>
   #all or (possibly empty) subset of {extension, restriction, list, union}</xs:documentation>
    </xs:annotation>
    <xs:union>
      <xs:simpleType>
        <xs:restriction base="xs:token">
          <xs:enumeration value="#all"/>
        </xs:restriction>
      </xs:simpleType>
      <xs:simpleType>
        <xs:list itemType="xs:typeDerivationControl"/>
      </xs:simpleType>
    </xs:union>
  </xs:simpleType>↑

E1-52 Error

See R-129 pfiS4SId, "type of id attr on schema elt" (note that this name is misleading, the issue was about the 'version' attribute).

Erratum E1-9 is withdrawn. The relevant declaration in §Appendix A: Schema for Schemas (normative) should remain as originally published, i.e.

<xs:attribute name="version" type="xs:token"/>

E1-51 Error

See R-117 pfianyTypeLax "Problem with processContents for the ur-type".

In §Appendix A Schema for Schemas (normative), change to the type definition for 'anyType', as follows:

    <xs:anyAttribute↑ processContents="lax"/>↑/>

E1-50 Editorial

[No issue for this]

In §Appendix A Schema for Schemas (normative), changes to the introductory paragraphs as follows:

The XML ↓Schema definition↓↑representation of the schema↑ for ↓XML Schema: Structures itself↓↑schema documents↑ is presented here as ↑a↑ normative part of the specification, and as an illustrative example of ↑how↑ the XML Schema ↓in↓↑language can↑ ↓defining↓↑define↑ itself ↓with the very↓↑using its own↑ constructs↓ that it defines↓. The names of XML Schema language types, elements, attributes and groups defined here are evocative of their purpose, but are occasionally verbose.

There is some annotation in comments, but a fuller annotation will require the use of embedded documentation facilities or a hyperlinked external annotation for which tools are not yet readily available.

Since ↓an XML Schema: Structures↓↑a schema document↑ is an XML document, it has optional XML and doctype declarations that are provided here for completeness. The root schema element defines a new schema. Since this is a schema for XML Schema: Structures, the targetNamespace references the XML Schema namespace itself.

and to the closing note, as follows:

Note: And that is the end of the schema for ↓XML Schema: Structures↓↑schema documents↑.

and in §Appendix G DTD for Schemas (non-normative), a change to the introductory paragraph as follows:

The DTD for ↓XML Schema: Structures↓↑schema documents↑ is given below. Note there is no implication here that schema must be the root element of a document.

E1-49 Clarification

See R-93 pfianyAttrRestrict, "Problem with derivation by restriction and anyAttribute" and R-117 pfianyTypeLax, "Problem with processContents for the ur-type".

In §3.10.1 The Wildcard Schema Component, in the description of values for the {process contents} property, changes as follows:

lax

If the item↓, or any items among its [children] if it's an element information item,↓ has a uniquely determined declaration available, it must be ·valid· with respect to that definition, that is, ·validate· ↓where↓↑if↑ you can, don't worry ↓when↓↑if↑ you can't.

E1-48 Clarification

A number of errata (E1-43, E1-22, E1-21, E1-15) in this document have made changes to clauses 4 and 5 of §3.4.6 Schema Component Constraint: Derivation Valid (Restriction, Complex). The net result is as follows:

Schema Component Constraint: Derivation Valid (Restriction, Complex)

If the {derivation method} is restriction all of the following must be true:

4 If there is an {attribute wildcard}, all of the following must be true:

4.1 The {base type definition} must also have one.

4.2 The complex type definition's {attribute wildcard}'s {namespace constraint} must be a subset of the {base type definition}'s {attribute wildcard}'s {namespace constraint}, as defined by Wildcard Subset (§3.10.6).

↑

4.3 Unless the {base type definition} is the ·ur-type definition·, the complex type definition's {attribute wildcard}'s {process contents} must be identical to or stronger than the {base type definition}'s {attribute wildcard}'s {process contents}, where strict is stronger than lax is stronger than skip.

↑

5 One of the following must be true:

↑

5.1 The {base type definition} must be the ·ur-type definition·.

↑

5.2 All of the following must be true:

5.2.1 The {content type} of the complex type definition must be a simple type definition

5.2.2 One of the following must be true:

5.2.2.1 The {content type} of the {base type definition} must be a simple type definition ↓of↓↑from↑ which the {content type} is ↓a ·valid restriction·↓ ↑validly derived given the empty set↑ as defined in ↓Derivation Valid (Restriction, Simple) (§3.14.6)↓↑Type Derivation OK (Simple) (§3.14.6)↑.

5.2.2.2 The {base type definition} must be mixed and have a particle which is ·emptiable· as defined in Particle Emptiable (§3.9.6).

5.3 All of the following must be true:

5.3.1 The {content type} of the complex type itself must be empty

5.3.2 One of the following must be true:

5.3.2.1 The {content type} of the {base type definition} must also be empty.

5.3.2.2 The {content type} of the {base type definition} must be elementOnly or mixed and have a particle which is ·emptiable· as defined in Particle Emptiable (§3.9.6).

5.4 All of the following must be true:

5.4.1

↓

the {content type} of the {base type definition} is mixed or the {content type} of the complex type definition itself is element-only

↓

↑

One of the following must be true:

5.4.1.1 The {content type} of the complex type definition itself must be element-only

5.4.1.2 The {content type} of the complex type definition itself and of the {base type definition} must be mixed

↑

5.4.2 The particle of the complex type definition itself must be a ·valid restriction· of the particle of the {content type} of the {base type definition} as defined in Particle Valid (Restriction) (§3.9.6).

↑

Note: Attempts to derive complex type definitions whose {content type} is element-only by restricting a {base type definition} whose {content type} is empty are not ruled out by this clause. However if the complex type definition itself has a non-pointless particle it will fail to satisfy Particle Valid (Restriction) (§3.9.6). On the other hand some type definitions with pointless element-only content, for example an empty <sequence>, will satisfy Particle Valid (Restriction) (§3.9.6) with respect to an empty {base type definition}, and so be valid restrictions.

↑

[Definition:]  If this constraint Derivation Valid (Restriction, Complex) (§3.4.6) holds of a complex type definition, it is a valid restriction of its {base type definition}.

E1-47 Error

See R-54 pfiur-type, "Request for clarification of ur-type", and pfiS4SanySimpleType, "The S4S contains derivations with anySimpleType as the base". This change supersedes the 13th change in E1-22.

In §3.14.6 Constraints on Simple Type Definition Schema Components, change the first paragraph as follows:

All simple type definitions ↑other than the ·simple ur-type definition· and the built-in primitive datatype definitions ↑(see Simple Type Definitions (§3.14)) must satisfy ↑both↑ the following constraints.

E1-46 Clarification

See R-78 pfiSubstGrpUPA, "Issue to do with definition of substitution groups, block, and UPA". This change supersedes the 2nd change in E1-23.

In §3.3.1 The Element Declaration Schema Component, changes as follows:

Element declarations are ↑potential ↑members of the substitution group, if any, identified by {substitution group affiliation}. ↓Membership↓↑Potential membership↑ is transitive but not symmetric; an element declaration is a ↑potential ↑member of any group of which its {substitution group affiliation} is a ↑potential ↑member. ↑Actual membership may be blocked by the effects of {substitution group exclusions} or {disallowed substitutions}, see below.↑

E1-45 Clarification

See R-109 pfiFacetConstraints, "Mismatch between Parts 1, 2 in facet constraints" (and also E1-25)

In §3.4.3 Constraints on XML Representations of Complex Type Definitions, changes as follows:

3.14.3 ↓(non-normative)↓ Constraints on XML Representations of Simple Type Definitions

E1-44 Editorial

[no issues list entry for this]

In §3.3.6 Constraints on Element Declaration Schema Components, change the 4th bullet of the first constraint as follows:

Schema Component Constraint: Element Declaration Properties Correct

All of the following must be true:

. . .

4 If there is ↓an↓↑a↑ {substitution group affiliation}, the {type definition} of the element declaration must be validly derived from the {type definition} of the {substitution group affiliation}, given the value of the {substitution group exclusions} of the {substitution group affiliation}, as defined in Type Derivation OK (Complex) (§3.4.6) (if the {type definition} is complex) or as defined in Type Derivation OK (Simple) (§3.14.6) (if the {type definition} is simple).

E1-43 Error

[No issues list entry for this one yet]

In §3.4.6 Constraints on Complex Type Definition Schema Components, changes as follows:

Schema Component Constraint: Derivation Valid (Restriction, Complex)

If the {derivation method} is restriction all of the following must be true:

. . .

5 One of the following must be true:

↑

5.1 The {base type definition} must be the ·ur-type definition·.

↑

E1-42 Editorial

See R-57 pfiTypoAssessment, "Inconsistent capitalization in section 2.1 of Structures".

In §2.1 Overview of XML Schema, change the description of schema-validity assessment as follows:

Schema-validity assessment has two aspects:

1 ↓determining↓↑Determining↑ local schema-validity, that is whether an element or attribute information item satisfies the constraints embodied in the relevant components of an XML Schema;

2 Synthesizing an overall validation outcome for the item, combining local schema-validity with the results of schema-validity assessments of its descendants, if any, and adding appropriate augmentations to the infoset to record this outcome.

E1-41 Clarification

(No entry in issues list for this one yet) -- "What is the actual value of an item validated with the simple ur-type definition (anySimpleType)?"

In §2.2.1.2 Simple Type Definition, add the following after the definition of the simple ur-type definition:

↑

The mapping from lexical space to value space is unspecified for items whose type definition is the ·simple ur-type definition·. Accordingly this specification does not constrain processors' behaviour in areas where this mapping is implicated, for example checking such items against enumerations, constructing default attributes or elements whose declared type definition is the ·simple ur-type definition·, checking identity constraints involving such items.

↑

↑

Note: The Working Group expects to return to this area in a future version of this specification.

↑

E1-40 Clarification

(No entry in issues list for this one yet) -- "What is the normalized value of an item validated with the simple ur-type definition (anySimpleType)?"

In §3.1.4 White Space Normalization during Validation, changes as follows:

↑

If the simple type definition used in an item's ·validation· is the ·simple ur-type definition·, the ·normalized value· must be determined as in the preserve case above.

↑

E1-39 Error

See R-161 pfiQnameRes, "QName resolution to components with no target namespace".

In §3.15.3 Constraints on XML Representations of Schemas, changes as follows:

Schema Representation Constraint: QName resolution (Schema Document)

For a ·QName· to resolve to a schema component of a specified kind all of the following must be true:

. . .

2 ↓its↓↑The component's↑ {↓local ↓name} matches the ·local name· of the ·QName·;

3 ↓its↓↑The component's↑ {target namespace} is identical to the ·namespace name· of the ·QName·;

4 The appropriate case among the following must be true:

↑

4.1 If the ·namespace name· of the ·QName· is ·absent·, then one of the following must be true:

4.1.1 The <schema> element information item of the schema document containing the ·QName· has no targetNamespace [attribute].

4.1.2 The <schema> element information item of the that schema document contains an <import> element information item with no namespace [attribute].

↑

4.2 otherwise ↓its↓↑the↑ ·namespace name·↑ of the ·QName·↑ is the same as one of the following:

4.2.1 ↓The target namespace↓↑The ·actual value· of the targetNamespace [attribute] of the <schema> element information item of the ↑schema document containing the ·QName·.

4.2.2 The ·actual value· of the namespace [attribute] of some <import> element information item contained in ↑the <schema> element information item of ↑that schema document.

.

E1-38 Error

See R-159 pfiAttrDefaults, "Bug in the spec wrt attribute defaults ".

In §3.4.5 Complex Type Definition Information Set Contributions, changes as follows:

Schema Information Set Contribution: Attribute Default Value

For each attribute use in the {attribute uses} whose {required} is false and whose {value constraint} is not ·absent· but whose {attribute declaration} does not match one of the attribute information items in the element information item's [attributes] as per clause 3.1 of Element Locally Valid (Complex Type) (§3.4.4) above, the post-schema-validation infoset has an attribute information item whose properties are as below added to the [attributes] of the element information item.

. . .

. . .

[schema normalized value]

The canonical lexical representation of the ↓{value constraint}↓↑·effective value constraint·↑ value.

[schema default]

The canonical lexical representation of the ↓{value constraint}↓↑·effective value constraint·↑ value.

E1-37 Clarification

See R-156 pfiMixedSimple, "Question about mixed='true' and simpleContent ".

In §3.4.3 Constraints on XML Representations of Complex Type Definitions, changes as follows:

Schema Representation Constraint: Complex Type Definition Representation OK

In addition to the conditions imposed on <complexType> element information items by the schema for schemas, all of the following must be true:

. . .

2 If the <simpleContent> alternative is chosen, all of the following must be true:

. . .

↑

Note: Although not explicitly ruled out either here or in Schema for Schemas (normative) (§A), specifying <xs:complexType . . .mixed='true' when the <simpleContent> alternative is chosen has no effect on the corresponding component, and should be avoided. This may be ruled out in a subsequent version of this specification.

↑

. . .

E1-36 Error

See R-137 pfiSubstGrpLocals, "Can substitution groups contain local elements?".

In §3.3.6 Constraints on Element Declaration Schema Components, changes as follows:

Schema Component Constraint: Element Declaration Properties Correct

All of the following must be true:

. . .

3

↑

If there is a non-·absent· {substitution group affiliation}, then {scope} must be global.

↑

. . .

E1-35 Error

See R-136 pfiXPathSelector, "Question about selector XPath expressions".

In §3.11.4 Identity-constraint Definition Validation Rules, changes as follows:

Validation Rule: Identity-constraint Satisfied

For an element information item to be locally ·valid· with respect to an identity-constraint all of the following must be true:

. . .

2 Each node in the ·target node set· is ↑either the context node or↑an element node among ↓the↓↑its↑ descendants↓ of the context node↓.

. . .

E1-34 Editorial

See R-125 pfiStruct4.3.2, "Editorial error in section 4.3.2 of Structures".

In §4.3 Layer 3: Schema Document Access and Web-interoperability, changes as follows:

4.3.2 How schema definitions are located on the Web

. . .

1. . . .
2. . . .
3. On the other hand, in case a document author (human or not) created a document with a particular schema in view, and warrants that some or all of the document ↓is ↓conforms to that schema, the schemaLocation and noNamespaceSchemaLocation [attributes] (in the XML Schema instance namespace, that is, http://www.w3.org/2001/XMLSchema-instance) (hereafter xsi:schemaLocation and xsi:noNamespaceSchemaLocation) are provided. The first records the author's warrant with pairs of URI references (one for the namespace name, and one for a hint as to the location of a schema document defining names for that namespace name). The second similarly provides a URI reference as a hint as to the location of a schema document with no targetNamespace [attribute].
   Unless directed otherwise, for example by the invoking application or by command line option, processors should attempt to dereference each schema document location URI in the ·actual value· of such xsi:schemaLocation and xsi:noNamespaceSchemaLocation [attributes], see details below.

E1-33 Error

See R-107 pfiIncludeNote, "Change required re: note in section 4.2.1 of Structures".

In §4.2.1 Assembling a schema for a single target namespace from multiple schema definition documents, changes as follows:

↓

Note

↓

As discussed in Missing Sub-components (§5.3), ·QName·s in XML representations may fail to ·resolve·, rendering components incomplete and unusable because of missing subcomponents. During schema construction, implementations ↓are likely to↓↑must↑ retain ·QName· values for such references, in case ↓subsequent processing provides a referent↓↑an appropriately-named component becomes available to discharge the reference by the time it is actually needed↑. ·Absent· target ·namespace name·s of such as-yet unresolved reference ·QName·s in <include>d components ↓should↓↑must↑ also be converted if clause 3.2 is satisfied.

E1-32 Editorial

See R-103 pfiPSVIDefn, "The term PSVI needs to be defined".

In §2.1 Overview of XML Schema, changes as follows:

An XML Schema consists of components such as type definitions and element declarations. These can be used to assess the validity of well-formed element and attribute information items (as defined in [XML-Infoset]), and furthermore may specify augmentations to those items and their descendants. This augmentation makes explicit information which may have been implicit in the original document, such as normalized and/or default values for attributes and elements and the types of element and attribute information items. ↑[Definition:]  We refer to the augmented infoset which results from conformant processing as defined in this specification as the post-schema-validation infoset, or PSVI↑.

E1-31 Error

See R-100 pfiAppendixH, "Issue re: description of overlapping for UPA, Appendix H".

In §Appendix H Analysis of the Unique Particle Attribution Constraint (non-normative), changes as follows:

• They are both element declaration particles one of ↓which is↓↑whose {name} and {target namespace} are that same as those of an element declaration↑ in the other's ·substitution group·.

E1-30 Error

See R-87 pfiStruct3.4.2, "Error in section 3.4.2 of Structures".

In §3.4.2 XML Representation of Complex Type Definitions, in the simple content case of the property mapping tableau for Complex Type Definitions, changes as follows:

Complex Type Definition with simple content Schema Component

Property Representation . . . {attribute wildcard} 1 [Definition:]  Let the local wildcard be defined as the appropriate case among the following: 1.1 If there is an <anyAttribute> present, then a wildcard based on the ·actual value·s of the namespace and processContents [attributes] and the <annotation> [children], exactly as for the wildcard corresponding to an <any> element as set out in XML Representation of Wildcard Schema Components (§3.10.2); 1.2 otherwise ·absent·. 2 [Definition:]  Let the complete wildcard be defined as the appropriate case among the following: 2.1 If there are no <attributeGroup> [children] corresponding to attribute groups with non-·absent· {attribute wildcard}s, then the ·local wildcard·. 2.2 If there are one or more <attributeGroup> [children] corresponding to attribute groups with non-·absent· {attribute wildcard}s, then the appropriate case among the following: 2.2.1 If there is an <anyAttribute> present, then a wildcard whose {process contents} and {annotation} are those of the ·local wildcard·, and whose {namespace constraint} is the intensional intersection of the {namespace constraint} of the ·local wildcard· and of the {namespace constraint}s of all the non-·absent· {attribute wildcard}s of the attribute groups corresponding to the <attributeGroup> [children], as defined in Attribute Wildcard Intersection (§3.10.6). 2.2.2 If there is no <anyAttribute> present, then a wildcard whose properties are as follows: {process contents} The {process contents} of the first non-·absent· {attribute wildcard} of an attribute group among the attribute groups corresponding to the <attributeGroup> [children]. {namespace constraint} The intensional intersection of the {namespace constraint}s of all the non-·absent· {attribute wildcard}s of the attribute groups corresponding to the <attributeGroup> [children], as defined in Attribute Wildcard Intersection (§3.10.6). {annotation} ·absent·. 3 The value is then determined by the appropriate case among the following: 3.1 If the <restriction> alternative is chosen, then the ·complete wildcard·; 3.2 If the <extension> alternative is chosen, then [Definition:]  let the base wildcard be defined as the appropriate case among the following: 3.2.1 If the type definition ·resolved· to by the ·actual value· of the base [attribute] is a complex type definition with an {attribute wildcard}, then that {attribute wildcard}. 3.2.2 otherwise ·absent·. The value is then determined by the appropriate case among the following: 3.2.1 If the ·base wildcard· is non-·absent·, then the appropriate case among the following: 3.2.1.1 If the ·complete wildcard· is ·absent·, then the ·base wildcard·. 3.2.1.2 otherwise a wildcard whose {process contents} and {annotation} are those of the ·complete wildcard·, and whose {namespace constraint} is the intensional union of the {namespace constraint} of the ↓·effective wildcard·↓↑·complete wildcard·↑ and of the ·base wildcard·, as defined in Attribute Wildcard Union (§3.10.6). . . .

E1-29 Clarification

See R-101 pfiUPAGrp, "Issue re: UPA and groups", and R-86 pfiUPA, "Request for clarification of UPA".

In §3.8.6 Constraints on Model Group Schema Components, changes as follows:

Schema Component Constraint: Unique Particle Attribution

A content model must be formed such that during ·validation· of an element information item sequence, the particle ↑component↑ contained directly, indirectly or ·implicitly· therein with which to attempt to ·validate· each item in the sequence in turn can be uniquely determined without examining the content or attributes of that item, and without any information about the items in the remainder of the sequence.

Note: This constraint reconstructs for XML Schema the equivalent constraints of [XML 1.0 (Second Edition)] and SGML. Given the presence of element substitution groups and wildcards, the concise expression of this constraint is difficult, see Analysis of the Unique Particle Attribution Constraint (non-normative) (§H) for further discussion.

↑

Since this constraint is expressed at the component level, it applies to content models whose origins (e.g. via type derivation and references to named model groups) are no longer evident. So particles at different points in the content model are always distinct from one another, even if they originated from the same named model group.

↑

E1-28 Editorial

See R-71 pfielemDeclConsist, "Editorial error in the text for Element Declarations Consistent".

In §3.8.6 Constraints on Model Group Schema Components, changes as follows:

Schema Component Constraint: Element Declarations Consistent

If the {particles} contains, either directly, indirectly (that is, within the {particles} of a contained model group, recursively) or ·implicitly· two or more element declaration particles with the same {name} and {target namespace}, then all their type definitions must be the same top-level definition, that is, all of the following must be true:

1 all their {type definition}s must have a non-·absent· ↓name↓↑{name}↑.

2 all their {type definition}s must have the same ↓name↓↑{name}↑.

3 all their {type definition}s must have the same ↓target namespace↓↑{target namespace}↑.

[Definition:]  A list of particles implicitly contains an element declaration if a member of the list contains that element declaration in its ·substitution group·.

E1-27 Error

See R-68 pfiSimpleContent, "Contradiction in Structures re: base for complexTypes with simpleContent".

In §3.4.2 XML Representation of Complex Type Definitions, changes as follows:

Complex Type Definition with simple content Schema Component

Property Representation . . . {content type} the appropriate case among the following: 1 If the type definition ·resolved· to by the ·actual value· of the base [attribute] is a complex type definition ↓(↓whose own {content type} ↓must be↓↑is↑ a simple type definition↓, see below)↓ and the <restriction> alternative is chosen, then starting from either 1.1 the simple type definition corresponding to the <simpleType> among the [children] of <restriction> if there is one; 1.2 otherwise (<restriction> has no <simpleType> among its [children]), the simple type definition which is the {content type} of the type definition ·resolved· to by the ·actual value· of the base [attribute] a simple type definition which restricts ↓that simple type definition↓↑the simple type definition identified in clause 1.1 or clause 1.2↑ with a set of facet components corresponding to the appropriate element information items among the <restriction>'s [children] (i.e. those which specify facets, if any), as defined in Simple Type Restriction (Facets) (§3.14.6); 2 If ↑the type definition ·resolved· to by the ·actual value· of the base [attribute] is a complex type definition whose own {content type} is mixed and a particle which is ·emptiable·, as defined in Particle Emptiable (§3.9.6) and the <restriction> alternative is chosen↑, then ↑starting from the simple type definition corresponding to the <simpleType> among the [children] of <restriction> (which must be present) a simple type definition which restricts that simple type definition with a set of facet components corresponding to the appropriate element information items among the <restriction>'s [children] (i.e. those which specify facets, if any), as defined in Simple Type Restriction (Facets) (§3.14.3);↑ 3 If the type definition ·resolved· to by the ·actual value· of the base [attribute] is a complex type definition (whose own {content type} must be a simple type definition, see below) and the <extension> alternative is chosen, then the {content type} of that complex type definition; 4 otherwise (the type definition ·resolved· to by the ·actual value· of the base [attribute] is a simple type definition and the <extension> alternative is chosen), then that simple type definition.

Also, in §3.4.3 Constraints on XML Representations of Complex Type Definitions, changes as follows:

Schema Representation Constraint: Complex Type Definition Representation OK

In addition to the conditions imposed on <complexType> element information items by the schema for schemas, all of the following must be true:

. . .

2 If the <simpleContent> alternative is chosen, all of the following must be true:

2.1 The type definition ·resolved· to by the ·actual value· of the base [attribute] must be one of the following:

2.1.1 a complex type definition whose {content type} is a simple type definition;

2.1.2

↑

only if the <restriction> alternative is also chosen, a complex type definition whose {content type} is mixed and a particle which is ·emptiable·, as defined in Particle Emptiable (§3.9.6);

↑

2.1.3 only if the <extension> alternative is also chosen, a simple type definition.

2.2

↑

If clause 2.1.2 above is satisfied, then there must be a <simpleType> among the [children] of <restriction>.

↑

E1-26 Clarification

See R-113 pfiall, "A question about all content models" and pfiallGroup, "minOccurs=0 on 'all'".

In §3.8.6 Constraints on Model Group Schema Components, changes as follows:

Schema Component Constraint: All Group Limited

When a model group has {compositor} all all of the following must be true:

1 ↓one of the following must be true:↓↑It appears only as the value of one or both of the following properties:↑

1.1 ↓It appears as the model group↓↑the {model group} property↑ of a model group definition.

1.2 ↓It appears in↓↑the {term} property of↑ a particle with ↓{min occurs}=↓{max occurs}=1↓, and that particle must be↓↑which is↑ part of a pair which constitutes the {content type} of a complex type definition.

2 The {max occurs} of all the particles in the {particles} of the group must be 0 or 1.

E1-25 Error

See R-109 pfiFacetConstraints, "Mismatch between Parts 1 and 2 in the area of facet constraints" (which E1-45 also addresses).

Move the following constraint as amended from §3.14.3 (non-normative) Constraints on XML Representations of Simple Type Definitions to §3.14.6 Constraints on Simple Type Definition Schema Components, thus changing it from a Representation Constraint to a Component Constraint and making it normative:

Schema ↓Representation↓↑Component↑ Constraint: Simple Type Restriction (Facets)

For a simple type definition (call it R) to restrict another simple type definition (call it B) with a set of facets (call this S) all of the following must be true:

1 The {variety} ↓and {primitive type definition}↓ of R ↓are↓↑is↑ the same as ↓those↓↑that↑ of B.

2

↑

If {variety} is atomic, the {primitive type definition} of R is the same as that of B.

↑

3 The {facets} of R are the union of S and the {facets} of B, eliminating duplicates. To eliminate duplicates, when a facet of the same kind occurs in both S and the {facets} of B, the one in the {facets} of B is not included, with the exception of enumeration and pattern facets, for which multiple occurrences with distinct values are allowed.

↑

Additional constraint(s) may apply depending on the kind of facet, see the appropriate sub-section of 4.3 Constraining Facets

↑

[Definition:]  If clause 2 above holds, the {facets} of R constitute a restriction of the {facets} of B with respect to S.

E1-24 Error

See R-102 pfisimpleTypeRestrict, "Errata in restriction constraints wrt simple type defns?".

In §3.14.6 Constraints on Simple Type Definition Schema Components, changes as follows:

Schema Component Constraint: Derivation Valid (Restriction, Simple)

The appropriate case among the following must be true:

1 . . .

2 If the {variety} is list, then all of the following must be true:

. . .

2.3 The appropriate case among the following must be true:

2.3.1 If the {base type definition} is ↓not↓ the ·simple ur-type definition· , then

. . .

2.3.2 otherwise all of the following must be true:

. . .

2.3.2.3

↑

The {item type definition} must be validly derived from the {base type definition}'s {item type definition} given the empty set, as defined in Type Derivation OK (Simple) (§3.14.6).

↑

3 If the {variety} is union, then all of the following must be true:

. . .

3.3 The appropriate case among the following must be true:

3.3.1 If the {base type definition} is ↓not↓ the ·simple ur-type definition· , then

. . .

3.3.2 otherwise all of the following must be true:

. . .

3.3.2.3

↑

The {member type definitions}, in order, must be validly derived from the corresponding type definitions in the {base type definition}'s {member type definitions} given the empty set, as defined in Type Derivation OK (Simple) (§3.14.6).

↑

E1-23 Error

See R-74 pficircularSubstGrp, "Missing constraint for circular substitution groups?", and R-78 pfiSubstGrpUPA, "Issue to do with definition of substitution groups, block, and UPA".

In §2.2.2 Declaration Components, changes as follows:

2.2.2.2 Element Substitution Group

In XML 1.0, the name and content of an element must correspond exactly to the element type referenced in the corresponding content model.

[Definition:]  Through the new mechanism of element substitution groups, XML Schemas provides a more powerful model supporting substitution of one named element for another. Any top-level element declaration can serve as the defining ↓element↓↑member↑, or head, for an element substitution group. Other top-level element declarations, regardless of target namespace, can be designated as members of the substitution group headed by this element. In a suitably enabled content model, a reference to the head ·validates· not just the head itself, but elements corresponding to any ↑other↑ member of the substitution group as well.

Also, in §3.3 Element Declarations, changes as follows:

[Superseded by E1-46]

Also, in §3.3.6 Constraints on Element Declaration Schema Components, changes as follows:

Schema Component Constraint: Element Declaration Properties Correct

All of the following must be true:

1 The values of the properties of an element declaration must be as described in the property tableau in The Element Declaration Schema Component (§3.3.1), modulo the impact of Missing Sub-components (§5.3).

2 If there is a {value constraint}, the canonical lexical representation of its value must be ·valid· with respect to the {type definition} as defined in Element Default Valid (Immediate) (§3.3.6).

3 If there is an {substitution group affiliation}, the {type definition} of the element declaration must be validly derived from the {type definition} of the {substitution group affiliation}, given the value of the {substitution group exclusions} of the {substitution group affiliation}, as defined in Type Derivation OK (Complex) (§3.4.6) (if the {type definition} is complex) or as defined in Type Derivation OK (Simple) (§3.14.6) (if the {type definition} is simple).

4 If the {type definition} or {type definition}'s {content type} is or is derived from ID then there must not be a {value constraint}.

Note: The use of ID as a type definition for elements goes beyond XML 1.0, and should be avoided if backwards compatibility is desired.

5

↑

Circular substitution groups are disallowed. That is, it must not be possible to return to an element declaration by repeatedly following the {substitution group affiliation} property.

↑

Also, in §3.3.6 Constraints on Element Declaration Schema Components, changes as follows:

Schema Component Constraint: Substitution Group OK (Transitive)

For an element declaration (call it D) ↓together with a blocking constraint (a subset of {substitution, extension, restriction}, the value of a {disallowed substitutions})↓ to be validly substitutable for another element declaration (call it C) ↑subject to a blocking constraint (a subset of {substitution, extension, restriction}, the value of a {disallowed substitutions})↑ one of the following must be true:

1

↑

D and C are the same element declaration.

↑

2 All of the following must be true:

2.1 The blocking constraint does not contain substitution.

2.2 There is a chain of {substitution group affiliation}s from D to C, that is, either D's {substitution group affiliation} is C, or D's {substitution group affiliation}'s {substitution group affiliation} is C, or . . .

2.3 The set of all {derivation method}s involved in the derivation of D's {type definition} from C's {type definition} does not intersect with the union of the blocking constraint, C's {prohibited substitutions} (if C is complex, otherwise the empty set) and the {prohibited substitutions} (respectively the empty set) of any intermediate {type definition}s in the derivation of D's {type definition} from C's {type definition}.

Schema Component Constraint: Substitution Group

[Definition:]  Every element declaration ↑(call this HEAD↑) in the {element declarations} of a schema defines a substitution group, a subset of those {element declarations}, as follows:

↑

Define P, the potential substitution group for HEAD, as follows:

↑

1 The element declaration itself is in ↓the group↓↑P↑;

2 ↓The group↓↑P↑ is closed with respect to {substitution group affiliation}, that is, if any element declaration in the {element declarations} has a {substitution group affiliation} in ↓the group↓↑P↑, then it is also in ↓the group↓↑P↑ itself.

↑

HEAD's actual ·substitution group· is then the set consisting of each member of P such that all of the following must be true:

1 Its {abstract} is false.

2 It is validly substitutable for HEAD subject to HEAD's {disallowed substitutions} as the blocking constraint, as defined in Substitution Group OK (Transitive) (§3.3.6).

↑

Also, in §3.9.6 Constraints on Particle Schema Components, changes as follows:

Schema Component Constraint: Particle Valid (Restriction)

[Definition:]  For a particle (call it R, for restriction) to be a valid restriction of another particle (call it B, for base) one of the following must be true:

1 They are the same particle.

2 depending on the kind of particle, per the table below, with the qualifications that all of the following must be true:

2.1 Any top-level element declaration particle (in R or B) which is the {substitution group affiliation} of one or more other element declarations ↑and whose ·substitution group· contains at least one element declaration other than itself↑ is treated as if it were a choice group whose {min occurs} and {max occurs} are those of the particle, and whose {particles} consists of one particle with {min occurs} and {max occurs} of 1 ↓for the top-level element declaration and↓ for each of the declarations in its ·substitution group·.

2.2 Any pointless occurrences of <sequence>, <choice> or <all> are ignored, where pointlessness is understood as follows:

<sequence>

One of the following must be true:

2.2.1 {particles} is empty.

2.2.2 All of the following must be true:

2.2.2.1 The particle within which this <sequence> appears has {max occurs} and {min occurs} of 1.

2.2.2.2 One of the following must be true:

2.2.2.2.1 The <sequence>'s {particles} has only one member.

2.2.2.2.2 The particle within which this <sequence> appears is itself among the {particles} of a <sequence>.

<all>

One of the following must be true:

2.2.1 {particles} is empty.

2.2.2 {particles} has only one member.

<choice>

One of the following must be true:

2.2.1 {particles} is empty and the particle within which this <choice> appears has {min occurs} of 0.

2.2.2 All of the following must be true:

2.2.2.1 The particle within which this <choice> appears has {max occurs} and {min occurs} of 1.

2.2.2.2 One of the following must be true:

2.2.2.2.1 The <choice>'s {particles} has only one member.

2.2.2.2.2 The particle within which this <choice> appears is itself among the {particles} of a <choice>.

Also, in §Appendix H Analysis of the Unique Particle Attribution Constraint (non-normative), changes as follows:

H Analysis of the Unique Particle Attribution Constraint (non-normative)

A specification of the import of Unique Particle Attribution (§3.8.6) which does not appeal to a processing model is difficult. What follows is intended as guidance, without claiming to be complete.

[Definition:]  Two non-group particles overlap if

• They are both element declaration particles whose declarations have the same {name} and {target namespace}.

or

• They are both element declaration particles one of which is in the other's ·substitution group·.

or

• They are both wildcards, and the intensional intersection of their {namespace constraint}s as defined in Attribute Wildcard Intersection (§3.10.6) is not the empty set.

or

• One is a wildcard and the other an element declaration, and the {target namespace} ↓of the element declaration, or↓ of any member of its ·substitution group·↓,↓ is ·valid· with respect to the {namespace constraint} of the wildcard.

E1-22 Error

See R-34 pfisimpleTypefinal, "Potential problem with description of final for simpleType in Structures", R-54 pfiur-type, "Request for clarification of ur-type", R-117 pfianyTypeLax, "Problem with processContents for the ur-type", R-138 pfiS4SanySimpleType, "The S4S contains derivations with anySimpleType as the base" and R-162 pfiStruct3.14.6, "Errors in section 3.14.6 of Structures".

In paragraph three of §2.2.1.1 Type Definition Hierarchy, changes as follows:

[Definition:]  A distinguished ↑complex type definition, the↑ ur-type definition, whose name is anyType↑ in the XML Schema namespace↑, is present in each ·XML Schema·, serving as the root of the type definition hierarchy for that schema. ↓The ur-type definition, whose name is anyType, has the unique characteristic that it can function as a complex or a simple type definition, according to context. Specifically, ·restrictions· of the ur-type definition can themselves be either simple or complex type definitions.↓

Also, in §2.2.1.2 Simple Type Definition, changes as follows:

Each simple type definition, whether built-in (that is, defined in [XML Schemas: Datatypes]) or user-defined, is a ·restriction· of some particular simple ·base type definition·. For the built-in primitive type definitions, this is ↓the simple version↓[Definition:]  ↑the simple ur-type definition, a special restriction↑ of the ·ur-type definition·, whose name is anySimpleType ↑in the XML Schema namespace↑. ↓This is in turn understood to be a restriction of the ·ur-type definition·.↓ ↑The ·simple ur-type definition· is considered to have an unconstrained lexical space, and a value space consisting of the union of the value spaces of all the built-in primitive datatypes and the set of all lists of all members of the value spaces of all the built-in primitive datatypes.↑

Simple types may also be defined whose members are lists of items themselves constrained by some other simple type definition, or whose membership is the union of the memberships of some other simple type definitions. ↑Such↑ list and union simple type definitions are also ↓understood as ↓restrictions of the ·simple ur-type definition·.

Also, in §2.2.1.3 Complex Type Definition, changes as follows:

Each complex type definition ↑other than the ·ur-type definition· ↑is either

• a restriction of a complex ·base type definition·

or

• an ·extension· of a simple or complex ·base type definition·↑.↑

↓or↓

↓

• a ·restriction· of the ·ur-type definition·.

↓

Also, in the third-to-the-last paragraph in §3.2.2 XML Representation of Attribute Declaration Schema Components, changes as follows (only the link has changed):

The default when no simple type definition is referenced or provided is the ·simple ur-type definition·, which imposes no constraints at all.

Also, in the next-to-the-last paragraph before the examples following the mapping for {type definition} in §3.3.2 XML Representation of Element Declaration Schema Components section, changes as follows:

Note that the above allows for two levels of defaulting for unspecified type definitions. An <element> with no referenced or included type definition will correspond to an element declaration which has the same type definition as the head of its substitution group if it identifies one, otherwise the ·ur-type definition·. This has the important consequence that the minimum valid element declaration, that is, one with only a name attribute and no contents, is also ↑(nearly)↑ the most general, validating any combination of text and element content and allowing any attributes↑, and providing for recursive validation where possible↑.

Also, in §3.4.6 Schema Component Constraint: Derivation Valid (Restriction, Complex) change clause 5.1.2.1 as follows:

5.1.2.1 The {content type} of the {base type definition} must be a simple type definition ↓of↓↑from↑ which the {content type} is ↓a ·valid restriction·↓ ↑validly derived given the empty set↑ as defined in ↓Derivation Valid (Restriction, Simple) (§3.14.6)↓↑Type Derivation OK (Simple) (§3.14.6)↑.

Also, in §3.4.7 Built-in Complex Type Definition, changes as follows:

3.4.7 Built-in Complex Type Definition

There is a complex type definition nearly equivalent to the ·ur-type definition· present in every schema by definition. It has the following properties:

Complex Type Definition of the Ur-Type

Property Value {name} anyType {target namespace} http://www.w3.org/2001/XMLSchema {base type definition} Itself {derivation method} restriction {content type} A pair consisting of mixed and a particle with the following properties: Property Value {min occurs} 1 {max occurs} 1 {term} a model group with the following properties: Property Value {compositor} sequence {particles} a list containing one particle with the following properties: Property Value {min occurs} 0 {max occurs} unbounded {term} a wildcard with ↓an any {namespace constraint}↓↑the following properties:↑ ↑ Property Value {namespace constraint} any {process contents} lax ↑ {attribute uses} The empty set {attribute wildcard} a wildcard with ↓{namespace constraint} is any ↓↑the following properties:↑: ↑ Property Value {namespace constraint} any {process contents} lax ↑ {final} The empty set {prohibited substitutions} The empty set {abstract} false

The mixed content specification together with the ↓unconstrained↓↑lax↑ wildcard ↓content model↓ and attribute specification produce the defining property for the ·ur-type definition·, namely that every ↓complex↓ type definition is (eventually) a restriction of the ·ur-type definition·: its permissions and requirements are ↑(nearly) ↑the least restrictive possible.

Also, following Schema Component Constraint: Particle Restriction OK (Elt:Elt -- NameAndTypeOK) change the Note as follows:

Note: The above constraint on {type definition} means that in deriving a type by restriction, any contained type definitions must themselves be explicitly derived by restriction from the corresponding type definitions in the base definition↑, or be one of the member types of a corresponding union.↑.

Also, in §3.14.1 (non-normative) The Simple Type Definition Schema Component, change the list of additional properties when {variety} is atomic as follows:

atomic

{primitive type definition}

A built-in primitive simple type definition↓ (or the ·simple ur-type definition·)↓.

See also E2-59.

Also, in the fifth paragraph after the tableau in §3.14.1 (non-normative) The Simple Type Definition Schema Component, changes as follows:

As described in Type Definition Hierarchy (§2.2.1.1), every simple type definition is a ·restriction· of some other simple type (the {base type definition}), which is the ·simple ur-type definition· if and only if the type definition in question is one of the built-in primitive datatypes, or a list or union type definition↑ which is not itself derived by restriction from a list or union respectively↑. Each atomic type is ultimately a restriction of exactly one such built-in ↑primitive datatype, which is its↑ {primitive type definition}.

Also, remove the third-to-the-last paragraph of that section:

↓

As discussed in Type Definition Hierarchy (§2.2.1.1), the ·ur-type definition· functions as a simple type when used as the ·base type definition· for the built-in primitive datatypes and for list and union type definitions. It is considered to have an unconstrained lexical space, and a value space consisting of the union of the value spaces of all the built-in primitive datatypes and the set of all lists of all members of the value spaces of all the built-in primitive datatypes.

↓

Also, change the next paragraph (the next-to-the-last in the section) as follows:

The ·simple ur-type definition· must not be named as the ·base type definition· of any user-defined ↑atomic ↑simple type↑ definition↑s: as it has no constraining facets, this would be incoherent.

Also, in §3.14.6 Constraints on Simple Type Definition Schema Components, changes as follows:

[Superseded by E1-47]

Also, in §3.14.6 Schema Component Constraint: Simple Type Definition Properties Correct, changes as follows:

Schema Component Constraint: Simple Type Definition Properties Correct

All of the following must be true:

1 The values of the properties of a simple type definition must be as described in the property tableau in Datatype definition, modulo the impact of Missing Sub-components (§5.3).

2 ↑All simple type definitions must be derived ultimately from the ·simple ur-type definition (so·↑ circular definitions are disallowed↑)↑. That is, it must be possible to reach a built-in primitive datatype or the ·simple ur-type definition· by repeatedly following the {base type definition}.

3 The {final} of the {base type definition} must not contain restriction.

↓

4 If the {base type definition} is not the ·simple ur-type definition·, all of the following must be true:

4.1 The definition must be a ·valid restriction· as defined in Derivation Valid (Restriction, Simple) (§3.14.6).

4.2 If {variety} is not atomic, then the appropriate case among the following must be true:

4.2.1 If the {variety} is list, then the {final} of the {base type definition} must not contain list.

4.2.2 If the {variety} is union, then the {final} of the {base type definition} must not contain union.

↓

Also, in §3.14.6 Schema Component Constraint: Derivation Valid (Restriction, Simple), changes as follows:

Schema Component Constraint: Derivation Valid (Restriction, Simple)

The appropriate case among the following must be true:

1 If the {variety} is atomic, then all of the following must be true:

1.1 The {base type definition} must be an atomic simple type definition or a built-in primitive datatype.

1.2 The {final} of the {base type definition} must not contain restriction.

1.3 For each facet in the {facets}↑ (call this DF)↑ all of the following must be true:

1.3.1

↑

DF must be an allowed constraining facet for the {primitive type definition}, as specified in the appropriate subsection of §3.2 Primitive datatypes.

↑

1.3.2 ↑If ↑there ↓must be↓↑is↑ a facet of the same kind in the {facets} of the {base type definition}↑ (call this BF),↑↓of whose {value}↓↑then ↑the ↓facet in question↓↑DF↑'s {value} must be a valid restriction ↑of BF's {value} ↑as defined in [XML Schemas: Datatypes].

2 If the {variety} is list, then all of the following must be true:

2.1 The {item type definition} must have a {variety} of atomic or union (in which case all the {member type definitions} must be atomic).

2.2

↓

Only length, minLength, maxLength, pattern and enumeration facet components are allowed among the {facets}.

↓

2.3 The appropriate case among the following must be true:

2.3.1 If the {base type definition} is ↓not↓ the ·simple ur-type definition· , then

↑

all of the following must be true:

2.3.1.1 The {final} of the {item type definition} must not contain list.

2.3.1.2 The {facets} must only contain the whiteSpace facet component.

↑

2.3.2 otherwise all of the following must be true:

2.3.2.1 The {base type definition} must have a {variety} of list.

2.3.2.2 The {final} of the {base type definition} must not contain restriction.

2.3.2.3

↑

The {item type definition} must be validly derived from the {base type definition}'s {item type definition} given the empty set, as defined in Type Derivation OK (Simple) (§3.14.6).

↑

2.3.2.4

↑

Only length, minLength, maxLength, whiteSpace, pattern and enumeration facet components are allowed among the {facets}.

↑

2.3.2.5 For each facet in the {facets}↑ (call this DF), if ↑there ↓must be↓↑is↑ a facet of the same kind in the {facets} of the {base type definition}↑ (call this BF),↑↓of whose {value}↓↑then ↑the ↓facet in question↓↑DF↑'s {value} must be a valid restriction ↑of BF's {value} ↑ as defined in [XML Schemas: Datatypes].

↑

The first case above will apply when a list is derived by specifying an item type, the second when derived by restriction from another list.

↑

3 If the {variety} is union, then all of the following must be true:

3.1 The {member type definitions} must all have {variety} of atomic or list.

3.2

↓

Only pattern and enumeration facet components are allowed among the {facets}.

↓

3.3 The appropriate case among the following must be true:

3.3.1 If the {base type definition} is ↓not↓ the ·simple ur-type definition· , then

↑

all of the following must be true:

3.3.1.1 All of the {member type definitions} must have a {final} which does not contain union.

3.3.1.2 The {facets} must be empty.

↑

3.3.2 otherwise all of the following must be true:

3.3.2.1 The {base type definition} must have a {variety} of union.

3.3.2.2 The {final} of the {base type definition} must not contain restriction.

3.3.2.3

↑

The {member type definitions}, in order, must be validly derived from the corresponding type definitions in the {base type definition}'s {member type definitions} given the empty set, as defined in Type Derivation OK (Simple) (§3.14.6).

↑

3.3.2.4

↑

Only pattern and enumeration facet components are allowed among the {facets}.

↑

3.3.2.5 For each facet in the {facets}↑ (call this DF), if ↑there ↓must be↓↑is↑ a facet of the same kind in the {facets} of the {base type definition}↑ (call this BF),↑↓of whose {value}↓↑then ↑the ↓facet in question↓↑DF↑'s {value} must be a valid restriction ↑of BF's {value} ↑ as defined in [XML Schemas: Datatypes].

↑

The first case above will apply when a union is derived by specifying one or more member types, the second when derived by restriction from another union.

↑

Also, in §3.14.7 Built-in Simple Type Definition, change the introductory paragraph as follows:

There is a simple type definition nearly equivalent to the ↓simple version of the ↓·↑simple ↑ur-type definition· present in every schema by definition. It has the following properties:

Also, in §3.14.7 Built-in Simple Type Definition, add a new paragraph after the Simple Type Definition of the Ur-Type component display, and change the paragraph which currently follows it, as follows:

↑

The ·simple ur-type definition· is the root of the simple type definition hierarchy, and as such mediates between the other simple type definitions, which all eventually trace back to it via their {base type definition} properties, and the ·ur-type definition·, which is its {base type definition}. This is why the ·simple ur-type definition· is exempted from the first clause of Simple Type Definition Properties Correct (§3.14.6), which would otherwise bar it because of its derivation from a complex type definition and absence of {variety}.

↑

Simple type definitions for all the built-in primitive datatypes, namely string, boolean, float, double, number, dateTime, duration, time, date, gMonth, gMonthDay, gDay, gYear, gYearMonth, hexBinary, base64Binary, anyURI (see the Primitive Datatypes section of [XML Schemas: Datatypes])↓, as well as for the simple and complex ur-type definitions (as previously described),↓ are present by definition in every schema. All are in the XML Schema {target namespace} (namespace name http://www.w3.org/2001/XMLSchema), have an atomic {variety} with an empty {facets} and the ·simple ur-type definition· as their ·base type definition· and themselves as {primitive type definition}.

Also, in §Appendix F Glossary (non-normative), change entries as follows:

simple ur-type definition

↑the simple ur-type definition, a special restriction↑ of the ·ur-type definition·, whose name is anySimpleType↑ in the XML Schema namespace↑

ur-type definition

A distinguished ↑complex type definition, the↑ ur-type definition, whose name is anyType↑ in the XML Schema namespace↑, is present in each ·XML Schema·, serving as the root of the type definition hierarchy for that schema

Also, in §Appendix A Schema for Schemas (normative), changes as follows:

 <xs:complexType name="anyType" mixed="true">
  <xs:annotation>
   <xs:documentation>
   Not the real urType, but as close an approximation as we can
   get in the XML representation</xs:documentation>
  </xs:annotation>
  <xs:sequence>
   <xs:any minOccurs="0" maxOccurs="unbounded"↑ processContents="lax"↑/>
  </xs:sequence>
  <xs:anyAttribute/>
 </xs:complexType>

E1-21 Error

See R-93 pfianyAttrRestrict, "Problem with derivation by restriction and anyAttribute".

In §3.4.6 Constraints on Complex Type Definition Schema Components, changes as follows:

Schema Component Constraint: Derivation Valid (Restriction, Complex)

. . .

↑

4.3 Unless the {base type definition} is the ·ur-type definition·, the complex type definition's {attribute wildcard}'s {process contents} must be identical to or stronger than the {base type definition}'s {attribute wildcard}'s {process contents}, where strict is stronger than lax is stronger than skip.

↑

Also, in §3.9.6 Constraints on Particle Schema Components, changes as follows:

Schema Component Constraint: Particle Derivation OK (Any:Any -- NSSubset)

. . .

↑

3 Unless B is the content model wildcard of the ·ur-type definition·, R's {process contents} must be identical to or stronger than B's {process contents}, where strict is stronger than lax is stronger than skip.

↑

Note:

↑

The exception to the third clause above for derivations from the ·ur-type definition· is necessary as its wildcards have a {process contents} of lax, so without this exception, no use of wildcards with {process contents} of skip would be possible.

↑

E1-20 Error

See R-52 pfiCircularAttrGrp, "Missing constraint for indirect circular attribute group?".

In §3.6.3 Constraints on XML Representations of Attribute Group Definitions, changes as follows:

Schema Representation Constraint: Attribute Group Definition Representation OK

In addition to the conditions imposed on <attributeGroup> element information items by the schema for schemas, all of the following must be true:

1 The corresponding attribute group definition, if any, must satisfy the conditions set out in Constraints on Attribute Group Definition Schema Components (§3.6.6).

2 If clause 2.2.1 or clause 2.2.2 in the correspondence specification in XML Representation of Complex Type Definitions (§3.4.2) for {attribute wildcard}, as referenced above, is satisfied, the intensional intersection must be expressible, as defined in Attribute Wildcard Intersection (§3.10.6).

3 Circular group reference is disallowed outside <redefine>. That is, unless this element information item's parent is <redefine>, then among the [children], if any, there must not be an <attributeGroup> with ref [attribute] which resolves to the component corresponding to this <attributeGroup>. ↑Indirect circularity is also ruled out. That is, when QName resolution (Schema Document) (§3.15.3) is applied to a ·QName· arising from any <attributeGroup>s with a ref [attribute] among the [children], it must not be the case that a ·QName· is encountered at any depth which resolves to the component corresponding to this <attributeGroup>.↑

E1-19 Clarification

See R-33 pfiIdConstraint, "Request for clarification of identity constraint rules".

In §3.11.4 Identity-constraint Definition Validation Rules, after the validation rule for identity constraints, changes as follows:

↑

Note: Because the validation of keyref (see clause 4.3 of Validation Rule: Identity-constraint Satisfied) depends on finding appropriate entries in a element information item's ·node table·, and ·node tables· are assembled strictly recursively from the node tables of descendants, only element information items within the sub-tree rooted at the element information item being ·validated· can be referenced successfully.

↑

E1-18 Error

See R-66 pfiENTITY, "Magic built-in datatypes: ENTITY and ENTITIES".

In §3.14.4 Simple Type Definition Validation Rules, changes as follows::

Validation Rule: String Valid

For a string to be locally ·valid· with respect to a simple type definition all of the following must be true:

1 It is schema-valid with respect to that definition as defined by Datatype Valid in [XML Schemas: Datatypes].

↑

2 The appropriate case among the following must be true:

2.1 If The definition is ENTITY or is validly derived from ENTITY given the empty set, as defined in Type Derivation OK (Simple) (§3.14.6), then the string must be a ·declared entity name·.

2.2 If The definition is ENTITIES or is validly derived from ENTITIES given the empty set, as defined in Type Derivation OK (Simple) (§3.14.6), then every whitespace-deliminted substring of the string must be a ·declared entity name·.

2.3 otherwise no further condition applies.

↑

↑

[Definition:]  A string is a declared entity name if it is equal to the [name] of some unparsed entity information item in the value of the [unparsedEntities] property of the document information item at the root of the infoset containing the element or attribute information item whose ·normalized value· the string is.

↑

Also, in §Appendix D Required Information Set Items and Properties (normative), changes as follows:

This specification requires as a precondition for ·assessment· an information set as defined in [XML-Infoset] which supports at least the following information items and properties:

. . .

↑

In addition, infosets should support the [unparsedEntities] property of the Document Information Item. Failure to do so will mean all items of type ENTITY or ENTITIES will fail to ·validate·.

↑

E1-17 Clarification

See R-67 pfiTypeDerivation, "A question about type derivation and anonymous types".

[Superseded by E1-54]

E1-16 Error

See R-32 pfipublic, "Type of public attribute of notation", and R-153 pfipublicAttr, "Is the public attribute of notation optional?".

In §3.12.2 XML Representation of Notation Declaration Schema Components, changes as follows:

3.12.2 XML Representation of Notation Declaration Schema Components

The XML representation for a notation declaration schema component is a <notation> element information item. The correspondences between the properties of that information item and properties of the component it corresponds to are as follows:

XML Representation Summary: notation Element Information Item

<notation
  id = ID
  name = NCName
  ↓public↓↑public↑ = ↓anyURI↓↑token↑
  system = anyURI
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</notation>

Also, in §Appendix A Schema for Schemas (normative), changes as follows:

. . .

 <xs:element name="notation" id="notation">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#element-notation"/>
  </xs:annotation>
  <xs:complexType>
   <xs:complexContent>
    <xs:extension base="xs:annotated">
     <xs:attribute name="name" type="xs:NCName" use="required"/>
     <xs:attribute name="public" type="xs:public"↓ use="required"↓/>
     <xs:attribute name="system" type="xs:anyURI"/>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

. . .

E1-15 Clarification

See R-47 pfiRestrictEmpty, "Request for clarification of complex type derivation restriction rules for empty base".

In §3.4.6 Schema Component Constraint: Derivation Valid (Restriction, Complex), change clause 5 as follows:

↓5 The appropriate case among the following must be true:↓

↓5.1 If the {content type} of the complex type definition is a simple type definition, then one of the following must be true:↓

↓5.1.1 The {content type} of the {base type definition} must be a simple type definition of which the {content type} is a ·valid restriction· as defined in Derivation Valid (Restriction, Simple) (§3.14.6).↓

↓5.1.2 The {base type definition} must be mixed and have a particle which is ·emptiable· as defined in Particle Emptiable (§3.9.6).↓

↓5.2 If the {content type} of the complex type itself is empty , then one of the following must be true:↓

↓5.2.1 The {content type} of the {base type definition} must also be empty.↓

↓5.2.2 The {content type} of the {base type definition} must be elementOnly or mixed and have a particle which is ·emptiable· as defined in Particle Emptiable (§3.9.6).↓

↓5.3 If the {content type} of the {base type definition} is mixed or the {content type} of the complex type definition itself is element-only, then the particle of the complex type definition itself must be a ·valid restriction· of the particle of the {content type} of the {base type definition} as defined in Particle Valid (Restriction) (§3.9.6).↓

↑

5 One of the following must be true:

5.1 All of the following must be true:

5.1.1 The {content type} of the complex type definition must be a simple type definition

5.1.2 One of the following must be true:

5.1.2.1 The {content type} of the {base type definition} must be a simple type definition of which the {content type} is a ·valid restriction· as defined in Derivation Valid (Restriction, Simple) (§3.14.6).

5.1.2.2 The {base type definition} must be mixed and have a particle which is ·emptiable· as defined in Particle Emptiable (§3.9.6).

5.2 All of the following must be true:

5.2.1 The {content type} of the complex type itself must be empty

5.2.2 One of the following must be true:

5.2.2.1 The {content type} of the {base type definition} must also be empty.

5.2.2.2 The {content type} of the {base type definition} must be elementOnly or mixed and have a particle which is ·emptiable· as defined in Particle Emptiable (§3.9.6).

5.3 All of the following must be true:

5.3.1 One of the following must be true:

5.3.1.1 The {content type} of the complex type definition itself must be element-only

5.3.1.2 The {content type} of the complex type definition itself and of the {base type definition} must be mixed

5.3.2 The particle of the complex type definition itself must be a ·valid restriction· of the particle of the {content type} of the {base type definition} as defined in Particle Valid (Restriction) (§3.9.6).

NOTE: Attempts to derive complex type definitions whose {content type} is element-only from a {base type definition} whose {content type} is empty are not ruled out by this clause. However if the complex type definition itself has a non-pointless particle it will fail to satisfy Particle Valid (Restriction) (§3.9.6). On the other hand some type definitions with pointless element-only content, for example an empty <sequence>, will satisfy Particle Valid (Restriction) (§3.9.6) with respect to an empty {base type definition}, and so be valid restrictions.

↑

E1-14 Error

See R-46 pfiIdConstrAnnot, "Minor inconsistency in definition of Identity Constraints".

In §3.11.1 The Identity-constraint Definition Schema Component change the description of the {annotation} property as follows:

Optional. ↓An annotation↓ ↑A set of annotations↑.

In §3.11.2 XML Representation of Identity-constraint Definition Schema Components change the mapping specification for the {annotation} property as follows:

The ↓annotation↓↑annotations↑ corresponding to the <annotation> element information item in the [children], if present, ↑ and in the <selector> and <field> [children], if present,↑ otherwise ·absent·.

E1-13 Error

See R-28 pfiElemValidType, "Element locally valid (type): rule about 'abstract'".

Change clause 2 of §3.3.4 Validation Rule: Element Locally Valid (Type) as follows:

2 ↓Its {abstract} must be false↓↑It must not have {abstract} with value true↑.

E1-12 Editorial

See R-26 pfiPSVITypos, "Two typos in section 3.3.5 of Structures".

Change clause 1.1.3 of the value specification for [validity] in 3.3.5 Schema Information Set Contribution: Assessment Outcome (Element) as follows:

1.1.3 Neither its [children] nor its [attributes] contains an information item (element or attribute respectively) with a ·context-determined declaration· of mustFind whose [validity] is ↓unknown↓↑notKnown↑.

Change the value specification for [member type definition] in 3.3.5 Schema Information Set Contribution: Element Validated by Type as follows:

If and only if that type definition is a simple type definition with {variety} union, or a complex type definition whose {content type} is a simple ↓thype↓↑type↑ definition with {variety} union, then an ·item isomorphic· to that member of the union's {member type definitions} which actually ·validated· the element item's ·normalized value·.

E1-11 Error

See R-80 pfiother, "Meaning of ##other".

Change the second bullet in the second full paragraph of §3.10.1 The Wildcard Schema Component as follows:

2. (not and a namespace name) ↓have any namespace↓ ↑are namespace-qualified with a namespace↑ other than the specified namespace↓ name, or are not namespace qualified↓;

E1-10 Error

See R-65 pfiWildCardConstr, "Issues with rules for wildcard subset, union and intersection".

Change §3.10.6 Schema Component Constraint: Wildcard Subset as follows:

Schema Component Constraint: Wildcard Subset

For a namespace constraint (call it sub) to be an intensional subset of another namespace constraint (call it super) one of the following must be true:

1 super must be any.

2 All of the following must be true:

2.1 sub must be a pair of not and a↑ value (a↑ namespace name or ·absent·↑)↑.

2.2 super must be a pair of not and the same value.

3 All of the following must be true:

3.1 sub must be a set whose members are either namespace names or ·absent·.

3.2 One of the following must be true:

3.2.1 super must be the same set or a superset thereof.

3.2.2 super must be a pair of not and a ↑value (a↑ namespace name or ·absent·↑)↑ and ↑neither↑ that value ↑nor ·absent·↑ must ↓not↓be in sub's set.

Change §3.10.6 Schema Component Constraint: Attribute Wildcard Union as follows:

Schema Component Constraint: Attribute Wildcard Union

For a wildcard's {namespace constraint} value to be the intensional union of two other such values (call them O1 and O2): the appropriate case among the following must be true:

1 If O1 and O2 are the same value, then that value must be the value.

2 If either O1 or O2 is any, then any must be the value.

3 If both O1 and O2 are sets of (namespace names or ·absent·), then the union of those sets must be the value.

4 If the two are negations of different ↑values (↑namespace ↓names,↓↑names or ·absent·),↑ then ↓the intersection is↓↑a pair of↑ not ↓expressible.↓↑and ·absent· must be the value.↑

5 If either O1 or O2 is a pair of not and a namespace name and the other is a set of (namespace names or ·absent·) ↑(call this set S)↑, then The appropriate case among the following must be true:

5.1 If the set ↑S↑ includes ↑both↑ the negated namespace ↓name,↓↑name and ·absent·,↑ then any must be the value.

5.2 If the set ↑S includes the negated namespace name but not ·absent·, then a pair of not and ·absent· must be the value.↑

↑5.3 If the set S includes ·absent· but not the negated namespace name,↑ ↑then the union is not expressible.↑

↑5.4 If the set S↑ does not include ↑either↑ the negated namespace ↓name,↓↑name or ·absent·,↑ then whichever of O1 or O2 is a pair of not and a namespace name must be the value.

↑6 If either O1 or O2 is a pair of not and ·absent· and the other is a set of (namespace names or ·absent·) ↑(again call this set S)↑, then The appropriate case among the following must be true:↑

↑6.1 If the set ↑S↑ includes ·absent·, then any must be the value.↑

↑6.2 If the set ↑S↑ does not include ·absent·, then a pair of not and ·absent· must be the value.↑

In the case where there are more than two values, the intensional ↓intersection↓↑union↑ is determined by identifying the intensional ↓intersection↓↑union↑ of two of the values as above, then the intensional ↓intersection↓↑union↑ of that value with the third (providing the first ↓intersection↓↑union↑ was expressible), and so on as required.

Change §3.10.6 Schema Component Constraint: Attribute Wildcard Intersection as follows:

Schema Component Constraint: Attribute Wildcard Intersection

For a wildcard's {namespace constraint} value to be the intensional intersection of two other such values (call them O1 and O2): the appropriate case among the following must be true:

1 If O1 and O2 are the same value, then that value must be the value.

2 If either O1 or O2 is any, then the other must be the value.

3 If either O1 or O2 is a pair of not and a ↑value (a↑ namespace name ↑or ·absent·)↑ and the other is a set of (namespace names or ·absent·), then that set, minus the negated ↓namespace name↓↑value if it was in the set, minus ·absent·↑ if it was in the set, must be the value.

4 If both O1 and O2 are sets of (namespace names or ·absent·), then the intersection of those sets must be the value.

5 If the two are negations of different namespace names, then the intersection is not expressible.

↑6 If the one is a negation of a namespace name and the other is a negation of ·absent·, then the one which is the negation of a namespace name must be the value.↑

In the case where there are more than two values, the intensional intersection is determined by identifying the intensional intersection of two of the values as above, then the intensional intersection of that value with the third (providing the first intersection was expressible), and so on as required.

E1-9 Error

See R-129 pfiS4SId, "type of id attr on schema elt".

[Superseded by E1-52]

E1-8 Error

See R-143 pfiS4SanyAttr, "Subtle bug in schema doc for schemas".

All these changes have been made to the schema document at http://www.w3.org/2001/XMLSchema.xsd.

§Appendix A: Schema for Schemas (normative)

Add the following:

<anyAttribute namespace="##other"
             processContents="lax"/>

to all of the following complex type definitions:

topLevelAttribute
topLevelComplexType
localComplexType
complexRestrictionType
simpleRestrictionType
simpleExtensionType
topLevelElement
localElement
realGroup
namedGroup (and an anonymous type within it)
groupRef
explicitGroup
simpleExplicitGroup
an anonymous type with the group 'allModel'
all
namedAttributeGroup
attributeGroupRef
the anonymous type of the appinfo element declaration
the anonymous type of the documentation element declaration

E1-7 Error

See R-60 and R-42 pfiRestrictionSforS, "Problem with particle derivation rules and the Schema for Schemas" and pfichoicechoice, "Potential problem with particle derivation Choice:Choice rules".

All these changes have been made to the schema document at http://www.w3.org/2001/XMLSchema.xsd.

§Appendix A: Schema for Schemas (normative)

Change the definition of the allModel group from

 <xs:group name="allModel">
  <xs:sequence>
      <xs:element ref="xs:annotation" minOccurs="0"/>
      <xs:element name="element" ↓minOccurs="0" maxOccurs="unbounded"↓>
       <xs:complexType>
        <xs:annotation>
         <xs:documentation>restricted max/min</xs:documentation>
        </xs:annotation>
        <xs:complexContent>
         <xs:restriction base="xs:localElement">
          <xs:sequence>
           <xs:element ref="xs:annotation" minOccurs="0"/>
           <xs:choice minOccurs="0">
            <xs:element name="simpleType" type="xs:localSimpleType"/>
            <xs:element name="complexType" type="xs:localComplexType"/>
           </xs:choice>
           <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:attribute name="minOccurs" use="optional" default="1">
           <xs:simpleType>
            <xs:restriction base="xs:nonNegativeInteger">
             <xs:enumeration value="0"/>
             <xs:enumeration value="1"/>
            </xs:restriction>
           </xs:simpleType>
          </xs:attribute>
          <xs:attribute name="maxOccurs" use="optional" default="1">
           <xs:simpleType>
            <xs:restriction base="xs:allNNI">
             <xs:enumeration value="0"/>
             <xs:enumeration value="1"/>
            </xs:restriction>
           </xs:simpleType>
          </xs:attribute>
         </xs:restriction>
        </xs:complexContent>
       </xs:complexType>
      </xs:element>
     </xs:sequence>
 </xs:group>

to

 <xs:group name="allModel">
  <xs:sequence>
      <xs:element ref="xs:annotation" minOccurs="0"/>
      ↑<xs:choice minOccurs="0" maxOccurs="unbounded">
       <xs:annotation>
        <xs:documentation>This choice with min/max is here to
                          avoid a pblm with the Elt:All/Choice/Seq
                          Particle derivation constraint</xs:documentation>
       </xs:annotation>↑
       <xs:element name="element">
        <xs:complexType>
         <xs:annotation>
          <xs:documentation>restricted max/min</xs:documentation>
         </xs:annotation>
         <xs:complexContent>
          <xs:restriction base="xs:localElement">
           <xs:sequence>
            <xs:element ref="xs:annotation" minOccurs="0"/>
            <xs:choice minOccurs="0">
             <xs:element name="simpleType" type="xs:localSimpleType"/>
             <xs:element name="complexType" type="xs:localComplexType"/>
            </xs:choice>
            <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:attribute name="minOccurs" use="optional" default="1">
            <xs:simpleType>
             <xs:restriction base="xs:nonNegativeInteger">
              <xs:enumeration value="0"/>
              <xs:enumeration value="1"/>
             </xs:restriction>
            </xs:simpleType>
           </xs:attribute>
           <xs:attribute name="maxOccurs" use="optional" default="1">
            <xs:simpleType>
             <xs:restriction base="xs:allNNI">
              <xs:enumeration value="0"/>
              <xs:enumeration value="1"/>
             </xs:restriction>
            </xs:simpleType>
           </xs:attribute>
          </xs:restriction>
         </xs:complexContent>
        </xs:complexType>
       </xs:element>
      ↑</xs:choice>↑
     </xs:sequence>
 </xs:group>

§Appendix A: Schema for Schemas (normative)

Change the definition of the complexRestrictionType type definition from

 <xs:complexType name="complexRestrictionType">
  <xs:complexContent>
   <xs:restriction base="xs:restrictionType">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:group ref="xs:typeDefParticle" ↓minOccurs="0"↓/>
     <xs:group ref="xs:attrDecls"/>
    </xs:sequence>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>

to

 <xs:complexType name="complexRestrictionType">
  <xs:complexContent>
   <xs:restriction base="xs:restrictionType">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     ↑<xs:choice minOccurs="0">
      <xs:annotation>
       <xs:documentation>This choice is added simply to
                   make this a valid restriction per the REC</xs:documentation>
      </xs:annotation>↑
      <xs:group ref="xs:typeDefParticle"/>
     ↑</xs:choice>↑
     <xs:group ref="xs:attrDecls"/>
    </xs:sequence>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>

§Appendix A: Schema for Schemas (normative)

Change the definition of the simpleRestrictionType type definition from

 <xs:complexType name="simpleRestrictionType">
  <xs:complexContent>
   <xs:restriction base="xs:restrictionType">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:group ref="xs:simpleRestrictionModel" ↓minOccurs="0"↓/>
     <xs:group ref="xs:attrDecls"/>
    </xs:sequence>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>

to

 <xs:complexType name="simpleRestrictionType">
  <xs:complexContent>
   <xs:restriction base="xs:restrictionType">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     ↑<xs:choice minOccurs="0">
      <xs:annotation>
       <xs:documentation>This choice is added simply to
                   make this a valid restriction per the REC</xs:documentation>
      </xs:annotation>↑
      <xs:group ref="xs:simpleRestrictionModel"/>
     ↑</xs:choice>↑
     <xs:group ref="xs:attrDecls"/>
    </xs:sequence>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>

§Appendix A: Schema for Schemas (normative)

Change the definition of the restrictionType type definition from

 <xs:complexType name="restrictionType">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:sequence>
     <xs:choice>
      <xs:group ref="xs:typeDefParticle" ↓minOccurs="0"↓/>
      <xs:group ref="xs:simpleRestrictionModel" ↓minOccurs="0"↓/>
     </xs:choice>
     <xs:group ref="xs:attrDecls"/>
    </xs:sequence>
    <xs:attribute name="base" type="xs:QName" use="required"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>

to

 <xs:complexType name="restrictionType">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:sequence>
     <xs:choice ↑minOccurs="0"↑>
      <xs:group ref="xs:typeDefParticle"/>
      <xs:group ref="xs:simpleRestrictionModel"/>
     </xs:choice>
     <xs:group ref="xs:attrDecls"/>
    </xs:sequence>
    <xs:attribute name="base" type="xs:QName" use="required"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>

E1-6 Clarification

See R-62 pfiIdConstrWhiteSp, "Whitespace and identity constraint XPath expressions".

§3.11.6 Schema Component Constraint: Selector Value OK

Add the following to the end of the constraint:

For readability, whitespace may be used in selector XPath expressions even though not explicitly allowed by the grammar: whitespace may be freely added within patterns before or after any token.

Lexical productions

[5]    token    ::=    '.' | '/' | '//' | '|' | '@' | NameTest [6]    whitespace    ::=    S

When tokenizing, the longest possible token is always returned.

Schema Component Constraint: Fields Value OK

Add the following to the end of the constraint:

For readability, whitespace may be used in field XPath expressions even though not explicitly allowed by the grammar: whitespace may be freely added within patterns before or after any token.

When tokenizing, the longest possible token is always returned.

E1-5 Error

See R-64 pfiComplexTypeMapping, "Issue with complex type property mapping rules for content type".

§3.4.2 Property mapping for complex type definitions with complex content

Replace the mapping for the {content type} property in the tableau headed "Complex Type Definition with complex content Schema Component" as follows:

{content type}

[Definition:]  Let the effective mixed be the appropriate case among the following: 1 If the mixed [attribute] is present on <complexContent>, then its ·actual value·; 2 If the mixed [attribute] is present on <complexType>, then its ·actual value·; 3 otherwise false. [Definition:]  Let the effective content be the appropriate case among the following: 1 If one of the following is true 1.1 There is no <group>, <all>, <choice> or <sequence> among the [children]; 1.2 There is an <all> or <sequence> among the [children] with no [children] of its own excluding <annotation>; 1.3 There is a <choice> among the [children] with no [children] of its own excluding <annotation> whose minOccurs [attribute] has the ·actual value· 0; , then the appropriate case among the following: 1.1 If the ·effective mixed· is true, then A particle whose properties are as follows: {min occurs} 1 {max occurs} 1 {term} A model group whose {compositor} is sequence and whose {particles} is empty. . 1.2 otherwise empty 2 otherwise the particle corresponding to the <all>, <choice>, <group> or <sequence> among the [children]. Then the value of the property is the appropriate case among the following: 1 If the <restriction> alternative is chosen, then the appropriate case among the following: 1.1 If the ·effective content· is empty , then empty; 1.2 otherwise a pair consisting of 1.2.1 mixed if the ·effective mixed· is true, otherwise elementOnly 1.2.2 The ·effective content·. 2 If the <extension> alternative is chosen, then the appropriate case among the following: 2.1 If the ·effective content· is empty, then the {content type} of the type definition ·resolved· to by the ·actual value· of the base [attribute] 2.2 If the type definition ·resolved· to by the ·actual value· of the base [attribute] has a {content type} of empty, then a pair as per clause 1.2 above; 2.3 otherwise a pair of mixed or elementOnly (determined as per clause 1.2.1 above) and a particle whose properties are as follows: {min occurs} 1 {max occurs} 1 {term} A model group whose {compositor} is sequence and whose {particles} are the particle of the {content type} of the type definition ·resolved· to by the ·actual value· of the base [attribute] followed by the ·effective content·.

Schema Component Constraint: Derivation Valid (Extension)

Add the following as the second sub-clause of clause 1.4, and renumber the subsequent clauses appropriately

1.4.2 The {content type} of both the {base type definition} and the complex type definition itself must be empty.

E1-4 Error

See Rec Issue R-39 pfiDTDforSchema, "Error in the DTD for Schemas in Structures spec".

Appendix G: DTD for Schemas

Change the following element declarations

<!ELEMENT %complexContent; (%restriction;|%extension;)>
<!ELEMENT %simpleContent; (%restriction;|%extension;)>
<!ELEMENT %extension; (%particleAndAttrs;)>

to

<!ELEMENT %complexContent; ((%annotation;)?, (%restriction;|%extension;))>
<!ELEMENT %simpleContent; ((%annotation;)?, (%restriction;|%extension;))>
<!ELEMENT %extension; ((%annotation;)?, (%particleAndAttrs;))>

E1-3 Error

See Rec Issue R-19 pfigroup, "group element info item missing attributes".

Section 3.7.2 XML Representation of Model Group Definition Schema Components

Change the display of attributes and content model from:

  name = NCName>
  Content: (annotation?, (all | choice | sequence))
</group>

to

  id = ID
  maxOccurs = (nonNegativeInteger | unbounded)  : 1
  minOccurs = nonNegativeInteger : 1
  name = NCName
  ref = QName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (all | choice | sequence)?)
</group>

§Appendix A: Schema for Schemas

Change the namedGroup complex type definition from

 <xs:complexType name="namedGroup">
  <xs:annotation>
   <xs:documentation>Should derive this from realGroup, but too complicated
                      for now</xs:documentation>
  </xs:annotation>
  <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:choice minOccurs="1" maxOccurs="1">
      <xs:element name="all">
       <xs:complexType>
        <xs:complexContent>
         <xs:restriction base="xs:all">
          <xs:group ref="xs:allModel"/>
          <xs:attribute name="minOccurs" use="prohibited"/>
          <xs:attribute name="maxOccurs" use="prohibited"/>
         </xs:restriction>
        </xs:complexContent>
       </xs:complexType>
      </xs:element>
      <xs:element name="choice" type="xs:simpleExplicitGroup"/>
      <xs:element name="sequence" type="xs:simpleExplicitGroup"/>
     </xs:choice>
    </xs:sequence>
    <xs:attribute name="name" use="required" type="xs:NCName"/>
    <xs:attribute name="ref" use="prohibited"/>
    <xs:attribute name="minOccurs" use="prohibited"/>
    <xs:attribute name="maxOccurs" use="prohibited"/>
 </xs:complexType>

to

 <xs:complexType name="namedGroup">
  <xs:complexContent>
   <xs:restriction base="xs:realGroup">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:choice minOccurs="1" maxOccurs="1">
      <xs:element name="all">
       <xs:complexType>
        <xs:complexContent>
         <xs:restriction base="xs:all">
          <xs:group ref="xs:allModel"/>
          <xs:attribute name="minOccurs" use="prohibited"/>
          <xs:attribute name="maxOccurs" use="prohibited"/>
         </xs:restriction>
        </xs:complexContent>
       </xs:complexType>
      </xs:element>
      <xs:element name="choice" type="xs:simpleExplicitGroup"/>
      <xs:element name="sequence" type="xs:simpleExplicitGroup"/>
     </xs:choice>
    </xs:sequence>
    <xs:attribute name="name" use="required" type="xs:NCName"/>
    <xs:attribute name="ref" use="prohibited"/>
    <xs:attribute name="minOccurs" use="prohibited"/>
    <xs:attribute name="maxOccurs" use="prohibited"/>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>

E1-2 Clarification

See Rec Issue R-9 pfiallGroup, "minOccurs=0 on 'all'".

Section 3.8.6 Constraints on Model Group Schema Components

[Superseded by E1-26]

Change clause 1.2 as follows:

1.2 It appears in a particle with {min occurs}=↑0 or 1 and ↑{max occurs}=1, and that particle must be part of a pair which constitutes the {content type} of a complex type definition.

E1-1 Editorial

See Rec Issue R-20 pfitypeExampleTypo, "Typographical error in section 3.4.2 example".

Section 3.4.2 XML Representation of ComplexType Definitions

In the example, change the element declaration of "size", within type "length2" from:

    <xs:element name="size" type="xs:nonPositiveInteger"/>

to:

    <xs:element name="size" type="xs:nonNegativeInteger"/>

Also, change the element declaration of "size", within type "length3" from:

    <element name="size" type="xs:non-positive-integer"/>

to:

    <element name="size" type="xs:nonNegativeInteger"/>

E2-67 Error

See public comment on E2-18. This change supersedes and partially reverses the changes made in E2-18.

Note that in the text below insertions and deletions are shown vis à vis the published Recommendation. The differences from E2-18 are:

• reverse the insertion of XmlChar in the right-hand side of production [17]
• reverse the deletion of XmlCharIncDash in the right-hand side of production [17]
• reverse the deletion of production [22]
• reverse the deletion of the third bullet item in the list following production [22]
• insert a note (shown below) following the list following production [22]

In §F.1 Character Classes

Change productions 17 and 22 and the text which follows them as shown below:

Character Range

[17]    charRange    ::=    seRange | ↓XmlCharRef | ↓ XmlCharIncDash [18]    seRange    ::=    charOrEsc '-' charOrEsc ↓ [19]    XmlCharRef    ::=    ( '&#' [0-9]+ ';' ) | (' &#x' [0-9a-fA-F]+ ';' ) ↓ [20]    charOrEsc    ::=    XmlChar | SingleCharEsc [21]    XmlChar    ::=    [^\#x2D#x5B#x5D] [22]    XmlCharIncDash    ::=    [^\#x5B#x5D]

A single XML character is a ·character range· that identifies the set of characters containing only itself. All XML characters are valid character ranges, except as follows:

• The [, ], - and \ characters are not valid character ranges;
• The ^ character is only valid at the beginning of a ·positive character group· if it is part of a ·negative character group·
• The - character is a valid character range only at the beginning or end of a ·positive character group·.

Note: ↑The grammar for ·character range· as given above is ambiguous, but the second and third bullets above together remove the ambiguity.↑

E2-66 Error

See Rec Issue R-99 pfilengthFacet. This change supersedes E2-35.

§4.3.1.4 Constraints on length Schema Components

Change the length and minLength or maxLength constraint as follows:

Schema Component Constraint: length and minLength or maxLength

↓

It is an ·error· for both length and either of minLength or maxLength to be members of {facets}.

↓

↑

If length is a member of {facets} then

1 It is an error for minLength to be a member of {facets} unless

1.1 the {value} of minLength <= the {value} of length and

1.2 there is type definition from which this one is derived by one or more restriction steps in which minLength has the same {value} and length is not specified.

2 It is an error for maxLength to be a member of {facets} unless

2.1 the {value} of length <= the {value} of maxLength and

2.2 there is type definition from which this one is derived by one or more restriction steps in which maxLength has the same {value} and length is not specified.

↑

E2-65 Clarification

See Rec Issue R-18 pfipattern

These changes extend those of E2-30 for the same issue.

In §3.3.5 NMTOKENS, a change as follows:

[Definition:]   NMTOKENS represents the NMTOKENS attribute type from [XML 1.0 (Second Edition)]. The ·value space· of NMTOKENS is the set of finite, non-zero-length sequences of ·NMTOKEN·s. The ·lexical space· of NMTOKENS is the set of ↓white ↓space↑-↑separated lists of tokens, of which each token is in the ·lexical space· of NMTOKEN. The ·itemType· of NMTOKENS is NMTOKEN.

In §3.3.10 IDREFS, a change as follows:

[Definition:]   IDREFS represents the IDREFS attribute type from [XML 1.0 (Second Edition)]. The ·value space· of IDREFS is the set of finite, non-zero-length sequences of IDREFs. The ·lexical space· of IDREFS is the set of ↓white ↓space↑-↑separated lists of tokens, of which each token is in the ·lexical space· of IDREF. The ·itemType· of IDREFS is IDREF.

In §3.3.12 ENTITIES, a change as follows:

[Definition:]   ENTITIES represents the ENTITIES attribute type from [XML 1.0 (Second Edition)]. The ·value space· of ENTITIES is the set of finite, non-zero-length sequences of ·ENTITY·s that have been declared as unparsed entities in a document type definition. The ·lexical space· of ENTITIES is the set of ↓white ↓space↑-↑separated lists of tokens, of which each token is in the ·lexical space· of ENTITY. The ·itemType· of ENTITIES is ENTITY.

In §4.1.2.2 Derivation by list, a change as follows:

A ·list· datatype must be ·derived· from an ·atomic· or a ·union· datatype, known as the ·itemType· of the ·list· datatype. This yields a datatype whose ·value space· is composed of finite-length sequences of values from the ·value space· of the ·itemType· and whose ·lexical space· is composed of ↓white ↓space↑-↑separated lists of literals of the ·itemType·.

In §4.1.4 Validation Rule: Datatype Valid, a change as follows:

A string is datatype-valid with respect to a datatype definition if:

1 it ·match·es a literal in the ·lexical space· of the datatype, determined as follows:

1.1 if ·pattern· is a member of {facets}, then the string must be pattern valid (§4.3.4.4);

1.2 if ·pattern· is not a member of {facets}, then

1.2.1 if {variety} is ·atomic· then the string must ·match· a literal in the ·lexical space· of {base type definition}

1.2.2 if {variety} is ·list· then the string must be a sequence of ↓white ↓space↑-↑separated tokens, each of which ·match·es a literal in the ·lexical space· of {item type definition}

1.2.3 if {variety} is ·union· then the string must ·match· a literal in the ·lexical space· of at least one member of {member type definitions}

2 the value denoted by the literal ·match·ed in the previous step is a member of the ·value space· of the datatype, as determined by it being Facet Valid (§4.1.4) with respect to each member of {facets} (except for ·pattern·).

E2-64 Clarification

No issue for this one.

Modify the existing bibliographic entry for the revision of ISO 8601, and add a further entry, as follows:

↑ISO 8601:1998 Draft Revision↑

↑ ISO (International Organization for Standardization). Representations of dates and times, draft revision, 1998.↑

↓ISO 8601 Draft Revision↓↑ISO 8601:2000 Second Edition↑

ISO (International Organization for Standardization). Representations of dates and times, ↓draft revision, 2000↓↑second edition, 2000-12-15↑.

E2-63 Clarification

See Rec Issue R-120 pfidateCanonical and E2-41.

Change the first two changes made by E2-41 (the large change to §3.2.7 dateTime and the newly added §3.2.7.3) as follows:

3.2.7 dateTime

[Definition:]   dateTime values may be viewed as objects with integer-valued year, month, day, hour and minute properties, a decimal-valued second property, and a boolean timezoned property. Each such object also has one decimal-valued method or computed property, timeOnTimeline, whose value is always a decimal number; the values are dimensioned in seconds, the integer 0 is 0001-01-01T00:00:00 and the value of timeOnTimeline for other dateTime values is computed using the Gregorian algorithm as modified for leap-seconds. The timeOnTimeline values form two related "timelines", one for timezoned values and one for non-timezoned values. Each timeline is a copy of the ·value space· of decimal, with integers given units of seconds.

The ·value space· of dateTime is closely related to the dates and times described in ISO 8601. For clarity, the text above specifies a particular origin point for the timeline. It should be noted, however, that schema processors need not expose the timeOnTimeline value to schema users, and there is no requirement that a timeline-based implementation use the particular origin described here in its internal representation. Other interpretations of the ·value space· which lead to the same results (i.e., are isomorphic) are of course acceptable.

All timezoned times are Coordinated Universal Time (UTC, sometimes called "Greenwich Mean Time"). Other timezones indicated in lexical representations are converted to UTC during conversion of literals to values. "Local" or untimezoned times are presumed to be the time in the timezone of some unspecified locality as prescribed by the appropriate legal authority; currently there are no legally prescribed timezones which are durations whose magnitude is greater than 14 hours. The value of each numeric-valued property (other than timeOnTimeline) is limited to the maximum value within the interval determined by the next-higher property. For example, the day value can never be 32, and cannot even be 29 for month 02 and year 2002 (February 2002).

Note:

The date and time datatypes described in this recommendation were inspired by [ISO8601]. ↓The year 0001 is↓↑'0001' is the lexical representation of↑ the year 1 ↑of the ↑Common Era (↓C.E., sometimes called A.D.↓↑1 CE, sometimes written "AD 1" or "1 AD"↑). There is no year ↓0000↓↑0, and '0000' is not a valid lexical representation↑. ↓The↓↑'-0001' is the lexical representation of the↑ year 1 Before Common Era (↓B.C.E, sometimes called B.C.↓↑1 BCE, sometimes written "1 BC"↑)↓ is the year 0001↓.

↓

Users of negative years under this (1.0) version of this Recommendation should be aware that the interpretation of negative years under subsequent versions of this Recommendation is thus intended to be different from that under this version.

↓

↑

Those using this (1.0) version of this Recommendation to represent dates before the beginning of the Common Era should be aware that the interpretation of lexical representations beginning with a '-' is likely to change in subsequent versions.

↑

[ISO8601] makes no mention of the year ↓0000↓↑0↑; in [ISO8601-1998] ↓the year 0000↓↑the form '0000'↑ was disallowed and this recommendation ↓disallowed↓↑disallows↑ it as well. ↑However, ↑[ISO8601-2000], which became available just as we were ↓closing on this recommendation↓↑completing version 1.0↑, allows the ↓year 0000↓↑form '0000', representing the year 1 BCE↑. A number of external ↓commentors↓↑commentators↑ have also ↓pointed out that the year 0000 should be allowed↓↑suggested that '0000' be allowed, as the lexical representation for 1 BCE, which is the normal usage in astronomical contexts↑. ↓Thus, it is our intention in XML Schema 1.1 to allow the year 0000 in the dateTime, date, gYear, and gYearMonth datatypes. The year 0000 will correspond to 1 B.C.E. and will be a leap year.↓ ↑It is the intention of the XML Schema Working Group to allow '0000' as a lexical representation in the dateTime, date, gYear, and gYearMonth datatypes in a subsequent version of this Recommendation. '0000' will be the lexical representation of 1 BCE (which is a leap year), '-0001' will become the lexical representation of 2 BCE (not 1 BCE as in this (1.0) version), '-0002' of 3 BCE, etc.↑

3.2.7.1 Lexical representation

The ·· of dateTime consists of finite-length sequences of characters of the form: '-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? ↓(zzzzz)?↓↑(zzzzzz)?↑, where

• '-'? yyyy is a four-or-more digit optionally negative-signed numeral that represents the year; if more than four digits, leading zeros are prohibited, and '0000' is prohibited (see the Note above (§3.2.7); also note that a plus sign is not permitted);
• the remaining '-'s are separators between parts of the date portion;
• the first mm is a two-digit numeral that represents the month;
• dd is a two-digit numeral that represents the day;
• 'T' is a separator indicating that time-of-day follows;
• hh is a two-digit numeral that represents the hour; '24' is permitted if the minutes and seconds represented are zero, and the dateTime value so represented is the first instant of the following day (the hour property of a dateTime object in the ·value space· cannot have a value greater than 23);
• ':' is a separator between parts of the time-of-day portion;
• the second mm is a two-digit numeral that represents the minute;
• ss↓ ('.' s+)?↓ is a two-integer-digit numeral that represents the↑ whole↑ seconds;
• ↑

  '.' s+ (if present) represents the fractional seconds;

  ↑
• zzzzzz (if present) represents the timezone (as described ↓above↓↑below↑).

For example, 2002-10-10T12:00:00-05:00 (noon on 10 October 2002, Central Daylight Savings Time as well as Eastern Standard Time in the U.S.) is 2002-10-10T17:00:00Z, five hours later than 2002-10-10T12:00:00Z.

For further guidance on arithmetic with dateTimes and durations, see Adding durations to dateTimes (§E).

3.2.7.2 Canonical representation

Except for trailing fractional zero digits in the seconds representation, '24:00:00' time representations, and timezone (for timezoned values), the mapping from literals to values is one-to-one. Where there is more than one possible representation, the canonical representation is as follows: ↓redundant trailing zero digits in fractional-second literals are prohibited. An hour representation of '24' is prohibited. Timezoned values are canonically represented by appending 'Z' to the nontimezoned representation.↓

• ↑

  The 2-digit numeral representing the hour must not be '24';

  ↑
• ↑

  The fractional second string, if present, must not end in '0';

  ↑
• ↑for timezoned values, the timezone must be represented with 'Z'↑ (All timezoned dateTime values are UTC.).

3.2.7.3 Timezones

Timezones are durations with (integer-valued) hour and minute properties (with the hour magnitude limited to at most 14, and the minute magnitude limited to at most 59, except that if the hour magnitude is 14, the minute value must be 0); they may be both positive or both negative.

The lexical representation of a timezone is a string of the form: (('+' | '-') hh ':' mm) | 'Z', where

• hh is a two-digit numeral (with leading zeros as required) that represents the hours,
• mm is a two-digit numeral that represents the minutes,
• '+' indicates a nonnegative duration,
• '-' indicates a nonpositive duration.

The mapping so defined is one-to-one, except that '+00:00', ↓'00:00'↓↑'-00:00'↑, and 'Z' all represent the same zero-length duration timezone, UTC; 'Z' is its canonical representation.

When a timezone is added to a UTC dateTime, the result is the date and time "in that timezone". For example, 2002-10-10T12:00:00+05:00 is 2002-10-10T07:00:00Z and 2002-10-10T00:00:00+05:00 is 2002-10-09T19:00:00Z.

E2-62 Clarification

See Rec Issue R-151 pfiequalFacet (and E2-46).

In §4.2.2 ordered, change the fifth paragraph as follows:

The notation a <> b is used to indicate the case when a != b and neither a < b nor b < a. ↑ For any values a and b from different ·primitive· ·value space·s, a <> b. ↑

And add the following definitions immediately thereafter:

↑

[Definition:]  When a <> b, a and b are incomparable,[Definition:]  otherwise they are comparable.

↑

E2-61 Clarification

See Rec Issue R-88 pfiNOTATION (and E2-34).

In §3.2.19 NOTATION, change the third paragraph as follows:

For compatibility (see Terminology (§1.4)) NOTATION should be used only on attributes ↑and should only be used in schemas with no target namespace↑.

E2-60 Error

See Rec Issue R-116 pfipatternType and E2-37.

In §Appendix A Schema for Datatype Definitions (normative), change the declaration of the 'pattern' element as follows:

  <xs:element name="pattern" ↓type="xs:noFixedFacet"↓ id="pattern">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-pattern"/>
    </xs:annotation>
    ↑<xs:complexType>
      <xs:complexContent>
        <xs:restriction base="xs:noFixedFacet">
          <xs:sequence>
            <xs:element ref="xs:annotation" minOccurs="0"/>
          </xs:sequence>
          <xs:attribute name="value" type="xs:string" use="required"/>
          <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>↑
  </xs:element>

E2-59 Clarification

See Rec Issue R-138 pfiS4SanySimpleType, "The S4S contains derivations with anySimpleType as the base" and R-54 pfiur-type, "Request for clarification of ur-type" (and also E1-22).

In §2.5.2 Primitive vs. derived datatypes, change the definition of anySimpleType as follows:

[Definition:]   ↑ The simple ur-type definition is a special restriction of the ur-type definition whose name is anySimpleType in the XML Schema namespace. anySimpleType can be considered as the ·base type· of all ·primitive· datatypes. anySimpleType is considered to have an unconstrained lexical space and a ·value space· consisting of the union of the ·value space·s of all the ·primitive· datatypes and the set of all lists of all members of the ·value space·s of all the ·primitive· datatypes. ↑ ↓ There exists a conceptual datatype, whose name is anySimpleType, that is the simple version of the ur-type definition from [XML Schema Part 1: Structures]. anySimpleType can be considered as the ·base type· of all ·primitive· types. The ·value space· of anySimpleType can be considered to be the ·union· of the ·value space·s of all ·primitive· datatypes. ↓

Also, in §4.1.1 The Simple Type Definition Schema Component, change the list of additional properties when {variety} is atomic as follows:

atomic

{primitive type definition}

A ·built-in· ·primitive· datatype definition↓ (or the simple ur-type definition↓).

Also, in §Appendix A Schema for Datatype Definitions (normative), change the first paragraph of 'documentation' of the second 'annotation' as follows:

    <xs:documentation>
      First the built-in primitive datatypes.  These definitions are for
      information only, the real built-in definitions are magic.  ↓Note in
      particular that there is no type named 'anySimpleType'.  The
      primitives should really be derived from no type at all, and
      anySimpleType should be derived as a union of all the primitives.↓
    </xs:documentation>

E2-58 Editorial

See Rec Issue R-56 pfiDerivedDatatypes

In §2.5.2 Primitive vs. derived datatypes, change the last paragraph as follows:

As described in more detail in XML Representation of Simple Type Definition Schema Components (§4.1.2), each ·user-derived· datatype ·must· be defined in terms of another datatype in one of three ways: 1) by assigning ·constraining facet·s which serve to restrict the ·value space· of the ·user-derived· datatype to a subset of that of the ·base type·; 2) by creating a ·list· datatype whose ·value space· consists of finite-length sequences of values of its ·itemType·; or 3) by creating a ·union· datatype whose ·value space· consists of the union of the ↓·value space·↓↑·value space·s of↑ its ·memberTypes·.

E2-57 Error

See Rec Issue R-90 pfidateTime

In §3.2.6 duration, add a note as follows:

↑

Note:

All ·minimally conforming· processors ·must· support year values with a minimum of 4 digits (i.e., YYYY) and a minimum fractional second precision of milliseconds or three decimal digits (i.e. s.sss). However, ·minimally conforming· processors ·may· set an application-defined limit on the maximum number of digits they are prepared to support in these two cases, in which case that application-defined maximum number ·must· be clearly documented.

↑

Also, in §3.2.7 dateTime, add a note as follows:

↑

Note: See the conformance note in (§3.2.6) which applies to this datatype as well.

↑

Also, in §3.2.8 time, add a note as follows:

↑

Note: See the conformance note in (§3.2.6) which applies to the seconds part of this datatype as well.

↑

Also, in §3.2.9 date, add a note as follows:

↑

Note: See the conformance note in (§3.2.6) which applies to the year part of this datatype as well.

↑

Also, in §3.2.10 gYearMonth, add a note as follows:

↑

Note: See the conformance note in (§3.2.6) which applies to the year part of this datatype as well.

↑

Also, in §3.2.11 gYear, add a note as follows:

↑

Note: See the conformance note in (§3.2.6) which applies to the year part of this datatype as well.

↑

E2-56 Error

See Rec Issue R-199 pfifinalSimpletype

In §4.1.2 XML Representation of Simple Type Definition Schema Components, change the displayed form of the 'simpleType' element as follows:

<simpleType
  final = (#all | ↑List of ↑(list | union | restriction))
  id = ID
  name = NCName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (restriction | list | union))
</simpleType>

Also, in §Appendix A Schema for Datatype Definitions (normative), change the type definition of 'simpleDerivationSet' as follows:

  <xs:simpleType name="simpleDerivationSet">
    <xs:annotation>
      <xs:documentation>
   #all or (possibly empty) subset of {restriction, union, list}
   </xs:documentation>
      <xs:documentation>
   A utility type, not for public use</xs:documentation>
    </xs:annotation>
    <xs:union>
      <xs:simpleType>
        <xs:restriction base="xs:token">
          <xs:enumeration value="#all"/>
        </xs:restriction>
      </xs:simpleType>
      <xs:simpleType>
        ↑<xs:list>
          <xs:simpleType>↑
            <xs:restriction base="xs:derivationControl">
              <xs:enumeration value="list"/>
              <xs:enumeration value="union"/>
              <xs:enumeration value="restriction"/>
            </xs:restriction>
          </xs:simpleType>
        ↑</xs:list>
      </xs:simpleType>↑
    </xs:union>
  </xs:simpleType>

E2-55 Error

See Rec Issue R-89 pfiinteger This change supersedes the second change of E2-43.

§Appendix A Schema for Datatype Definitions (normative)

Change the simpleType definition of integer as follows:

  <xs:simpleType name="integer" id="integer">
    <xs:annotation>
      <xs:documentation
        source="http://www.w3.org/TR/xmlschema-2/#integer"/>
    </xs:annotation>
    <xs:restriction base="xs:decimal">
      <xs:fractionDigits value="0" fixed="true" id="integer.fractionDigits"/>
      ↑<xs:pattern value='[\-+]?[0-9]+'/>↑
    </xs:restriction>
  </xs:simpleType>

E2-54 Error

See Rec Issue R-17 pfibase64 and E2-9.

Change the material added by the second change in E2-9 as follows:

The lexical forms of base64Binary values are limited to the 65 characters of the Base64 Alphabet defined in [RFC 2045], i.e., a-z, A-Z, 0-9, the plus sign (+), the forward slash (/) and the equal sign (=), together with the characters defined in [XML 1.0 (Second Edition)] as white space. No other characters are allowed.

For compatibility with older mail gateways, [RFC 2045] suggests that base64 data should have lines limited to at most 76 characters in length. This line-length limitation is not mandated in the lexical forms of base64Binary data and must not be enforced by XML Schema processors.

The lexical space of base64Binary is given by the following grammar (the notation is that used in [XML 1.0 (Second Edition)]; legal lexical forms must match the Base64Binary production.

↓Base64Binary  ::=  S? B64quartet* Base64final?

B64quartet    ::=  B64 S? B64 S? B64 S? B64 S?

B64final      ::=  B64 S? B04 S? '=' S? '=' S?
                   | B64 S? B64 S? B16 S? '=' S?↓
↑Base64Binary  ::=  ((B64S B64S B64S B64S)*
                     ((B64S B64S B64S B64) |
                      (B64S B64S B16S '=') |
                      (B64S B04S '=' #x20? '=')))?

B64S         ::= B64 #x20?

B16S         ::= B16 #x20?

B04S         ::= B04 #x20?↑

B04         ::=  [AQgw]
B16         ::=  [AEIMQUYcgkosw048]
B64         ::=  [A-Za-z0-9+/]

Note that this grammar requires the number of non-whitespace characters in the lexical form to be a multiple of four, and for equals signs to appear only at the end of the lexical form; strings which do not meet these constraints are not legal lexical forms of base64Binary because they cannot successfully be decoded by base64 decoders.

↑

Note: The above definition of the lexical space is more restrictive than that given in [RFC 2045] as regards whitespace -- this is not an issue in practice. Any string compatible with the RFC can occur in an element or attribute validated by this type, because the ·whiteSpace· facet of this type is fixed to collapse, which means that all leading and trailing whitespace will be stripped, and all internal whitespace collapsed to single space characters, before the above grammar is enforced.

↑

The canonical lexical form of a base64Binary data value is the base64 encoding of the value which matches the Canonical-base64Binary production in the following grammar:

↓ Canonical-base64Binary  ::=  (B64line* B64lastline)?

B64line                 ::=  B64x15 B64x15 B64x15 B64x15 B64 #xA
                            /* 76 Base64 characters followed by newline */

B64x15               ::=  B64 B64 B64 B64 B64
                      ::=    B64 B64 B64 B64 B64
                      ::=    B64 B64 B64 B64 B64

B64lastline            ::=  B64x4? B64x4? B64x4? B64x4?
                       ::=     B64x4? B64x4? B64x4? B64x4?
                       ::=     B64x4? B64x4? B64x4? B64x4?
                       ::=     B64x4? B64x4? B64x4? B64x4?
                       ::=     B64x4? B64x4?
                       ::=     (B64x4 | B64 B64 B16 '=') | (B64 B04 '=='))
                       ::=  #xA


B04         ::=  [AQgw]
B16         ::=  [AEIMQUYcgkosw048]
B64         ::=  [A-Za-z0-9+/]
↓
↑Canonical-base64Binary  ::=  (B64 B64 B64 B64)*
                               ((B64 B64 B16 '=') | (B64 B04 '=='))?↑

↑

Note: For some values the canonical form defined above does not conform to [RFC 2045], which requires breaking with linefeeds at appropriate intervals.

↑

The length of a base64Binary value is the number of octets it contains. This may be calculated from the lexical form by removing whitespace and padding characters and performing the calculation shown in the pseudo-code below:

lex2    := killwhitespace(lexform)    -- remove whitespace characters
lex3    := strip_equals(lex2)         -- strip padding characters at end
length  := floor (length(lex3) * 3 / 4)         -- calculate length

Note on encoding: [RFC 2045] explicitly references US-ASCII encoding. However, decoding of base64Binary data in an XML entity is to be performed on the Unicode characters obtained after character encoding processing as specified by [XML 1.0 (Second Edition)]

E2-53 Clarification

See Rec Issue R-151 pfiequalFacet and E2-46

4.2.1 equal

Change the fourth and fifth bullets in the last paragraph added by E2-46 as follows:

• if a datatype T' is ·derived· by ·restriction· from ↓a↓↑an atomic↑ datatype T then the ·value space· of T' is a subset of the ·value space· of T. Values in the ·value space·s of T and T' can be compared according to the above rules
• if datatypes T' and T'' are ·derived· by ·restriction· from a common ↑atomic↑ ancestor T then the ·value space·s of T' and T'' may overlap. Values in the ·value space·s of T' and T'' can be compared according to the above rules