As of 18 March 2004 this document is closed. Four errata (E1-55, E2-65, E2-66, and E2-67) have been added since then, correcting, extending, and or rolling back earlier errata, in response to comments on the Proposed Edited Recommendations (see below).
The W3C XML Schema Working Group has folded all the errata published herein into a Proposed Edited Recommendation: W3C XML Schema Second Edition (primer, structures and datatypes). Note this is not version 1.1, for which requirements are still being decided on, just a new edition incorporating all the errata we have dealt with so far. Accordingly, any comments on these errata, identifying potential problems with them, are particularly welcome at this time -- please send them, including the errata number(s) in the subject line, to www-xml-schema-comments@w3.org (archive at http://lists.w3.org/Archives/Public/www-xml-schema-comments/).
This document records known errors in the XML Schema 1.0 Specification for which the XML Schema WG has approved fixes up to 1 March 2004. For subsequent errata, see the XML Schema Second Edition Errata
The errata are separated into 3 sections, corresponding to the 3 sections of the specification:
Errata for each part are numbered separately. Errata for Part 0 are numbered with a prefix beginning with "E0-", errata for Part 1 are identified by "E1-", and errata for Part 2 are numbered with "E2-". The errata within each section are classified as Error, Editorial or Clarification and listed in reverse chronological order of their date of publication. Three kinds of changes are highlighted: ↑new, added text↑, ↑changed text↑, and ↓deleted text↓.
See R-59, "Suggested changes for Appendix C of Primer", and E0-27.
Revise the third line of the first example as follows:
<!ENTITY eacute "↓é↓↑é↑"/>
See R-43, "Imprecise text in Table 1 of Primer".
Change Table 1 as follows:
Table 1. Occurrence Constraints for Elements and Attributes Elements
(minOccurs, maxOccurs) fixed, defaultAttributes
use, fixed, defaultNotes (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.
See R-44, "Grammatical errors in section 5.6 of the Primer".
Remove the first sentence of the third paragraph:
↓The
schemaLocationattribute 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
schemaLocationattribute 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.↑
See R-59, "Suggested changes for Appendix C of Primer".
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="↓é↓↑é↑"/>
See R-81, "Error in Primer example of identity constraints".
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 zipcodeandnumberwould be: {95819 872-AA}, {95819 926-AA}, {95819 833-AA}, {95819 455-BX}, and {63143 455-BX}. Clearly, these combinations do not distinguish between zipcodeandnumbercombinations 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 eachitemelement, the combined values of itspartNumattribute and itsproductNamechild must be unique.↑To define combinations of values, we simply ↓add↓↑use multiple↑
fieldelements to identify all the values involved↓. So, to add the part number value to our existing definition, we add a newfieldelement whosexpathattribute value,r:part/@number, identifies thenumberattribute ofpartelements that are children of thezipelements identified byr: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>↑
See R-121, "Import example in section 5.4 of Primer incorrect".
Change the fourth paragraph as follows:
Note however, that we cannot reuse the
shipToelement 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
USAddressfromaddress.xsd, and extend it to define a new type calledAnalyst↑ in the report schema↑ by adding the new elementsphoneand
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,stateandzip) are locally declared inipo.xsd, whoseelementFormDefaultisunqualified(by default). The other elements in the example are declared inreport.xsd, whoseelementFormDefaultis set toqualified. ↑
See R-126, "Suggested change for the Primer re: substitution group members".
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↑.)
See R-104, "Primer question re: integer and the fractionDigits facet".
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 whiteSpacefacet is applicable to this type, the only value that can be specified iscollapse.↑
Change Table B1.b as follows:
Table B1.b. Simple Types & Applicable Facets Simple Types Facets max
Inclusivemax
Exclusivemin
Inclusivemin
ExclusivetotalDigits 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 fractionDigitsfacet is applicable to this type, the only value that can be specified is zero.↑
See R-33, "Request for clarification of identity constraint rules".
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>
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
numberattribute (<field xpath="@number"/>) of those elements (<selector xpath="↑r:regions/↑r:zip/r:part"/>) must reference thepNumKeykey.
See R-3, "Primer states that all components must be repeated in restriction", and R-67, "A question about type derivation and anonymous types".
Change the second paragraph as follows:
For example, suppose we want to update our definition of ↓ the list of
itemsin an international↓↑a↑ purchase order so that it must contain ↓at least oneitemon order↓↑acomment↑; the schema shown inipo.xsdallows a↓nitems↓↑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,RestrictedPurchaseOrderTypewill inherit theorderDateattribute declaration fromPurchaseOrderType.↑
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.
See R-6, "Confusing table in the Primer".
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
See R-5, "Typographical error in section 2.8 example".
Change the first line of the first example as follows:
<xsd:element name="↓Item↓↑item↑" minOccurs="0" maxOccurs="unbounded">
See R-18, "Use of pattern facet for list type".
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
See R-36, "Font of text in section 2.5.2 of Primer incorrect".
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,productNameandshipDatewhich are all children ofletterBody, and text appears around the element ↓name↓↑name↑ which is the child of a child ofletterBody.
See R-45, "Inaccurate language in section 5.5 of Primer re: references to HTML".
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 elementhtmlExample, 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:
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
htmlExamplewhose content is defined by theanyelement. In general, ananyelement 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 namespacehttp://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 ofminOccursandmaxOccurs:
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/xhtmlto appear inside thehtmlExampleelement. Therefore4Q99html.xmlis 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 in4Q99html.xmlby itself can provide that guarantee. If such a guarantee is required, the value of theprocessContentsattribute should be set tostrict(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 thehtmlExampleelement.
Revise the seventh paragraph as follows:
In addition to the
anyelement which enables element content according to namespaces, there is a correspondinganyAttributeelement which enables attributes to appear in elements. For example, we can permit any ↑X↑HTML attribute to appear as part of thehtmlExampleelement by addinganyAttributeto 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 thehtmlExampleelement. For example:
Revise the fifth example as follows:
Change the final paragraph as follows:
Note that the
schemaLocationis 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.
See R-48, "Lexical representation of gMonth is inconsistent wrt ISO 8601".
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)
See R-50, "'appInfo' element in Primer vs. 'appinfo' element in Structures".
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
documentationand↓appInfo↓↑appinfo↑appear as subelements ofannotation, which may itself appear at the beginning of most schema constructions. To illustrate, the following example showsannotationelements appearing at the beginning of an element declaration and a complex type definition:
Change the list in Appendix E as follows:
↓appInfo↓↑appinfo↑:
2.6See R-55, "Typo in table 2 of the Primer".
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)
See R-58, "Errors in example in Appendix C of Primer".
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éal</city> <!-- etc. --> </purchaseOrder>
See R-69, "Problem in the regex grammar for charRange".
Revise Table D1 as follows:
Table D1. Examples of Regular Expressions Expression Match(es) [↑\↑-ae]x -x, ax, ex [ae↑\↑-]x ax, ex, -x
See R-80, "Meaning of ##other".
Change Table 4 as follows:
See R-82, "Three editorial errors in the Primer".
Change the first sentence of the fourth paragraph as follows:
Several facets can be applied to list types:
length,minLength,maxLength,↑pattern,↑ andenumeration.
See R-82, "Three editorial errors in the Primer".
Change the third sentence of the first paragraph as follows:
In the case of our report schema,
report.xsd, theselectorelement'sxpathattribute contains an XPath expression,↑r:↑regions/↑r:↑zip, that selects a list of all thezipelements 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
fieldelement whosexpathattribute value,↑r:↑part/@number, identifies thenumberattribute ofpartelements that are children of thezipelements identified by↑r:↑regions/↑r:↑zip:
See R-82, "Three editorial errors in the Primer".
Change the second paragraph as follows:
To ensure that the part-quantity elements have corresponding part descriptions, we say that the
numberattribute ( ↓<field>@number</field>↓↑<field xpath="@number"/>↑) of those elements (↓<selector>zip/part</selector>↓↑<selector xpath="r:zip/r:part"/>↑) must reference thepNumKeykey. This declaration ofnumberas akeyrefdoes not mean that its value must be unique, but it does mean there must exist apNumKeywith the same value.
See R-155, "4 Typos in the Primer".
Revise the last sentence of the section as follows:
In the case of the
quantityelement, it has an anonymous simple type derived from↓integer↓↑positiveInteger↑whose value ranges between 1 and 99.
See R-155, "4 Typos in the Primer".
Revise the last note at the end of Table 2 as follows:
(5) The "g" prefix signals time periods in the Gregorian ↓calender↓↑calendar↑.
See R-155, "4 Typos in the Primer".
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....
See R-155, "4 Typos in the Primer".
Revise Table D1 as follows:
Table D1. Examples of Regular Expressions Expression Match(es) Espa↓n↓ñola Española
See R-4, "Conflicting statements about Primer being normative/non-normative".
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 ↓.
See R-2, "Primer states that there are 15 facets".
Change the first sentence as follows:
XML Schema defines ↓ fifteen ↓ ↑ twelve ↑ facets which are listed in Appendix B.
(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, then3.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 thebase[attribute] is a complex type definition with an {attribute wildcard}, then that {at