See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0017.html

There are problems comparing certain durations because of the choice of dateTime values listed in section 3.2.6.2 of the DataTypes spec. The problem arises out of the fact that there is no century year that is a leapyear between 399 BC and AD 399.

Discussed again at the Feb. 12, 2004 telecon. See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004Feb/0066.html

Resolved to issue an erratum against 2e noting that algorithm is wrong and will be fixed next time (add requirement against 1.1)

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0189.html

The Schema Primer states "XML Schema defines fifteen facets which are listed in Appendix B", but there are only 12 facets.

An erratum will be added to the errata document indicating that there are twelve facets.

Erratum number is: E0-1.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0154.html

The Primer states: "Notice that types derived by restriction must repeat all the components of the base type definition that are to be included in the derived type". However, this is not true of attributes.

An erratum will be added to the errata document indicating that only particle components need to be repeated.

Erratum E0-21 added.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0155.html

The introduction of the Primer indicates that the Primer is non-normative, but the status section indicates it may be cited as a normative reference.

An erratum will be added indicating that the text in the Status section be modified to remove any statement that the Primer may be referenced normatively.

Erratum number is: E0-2.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0159.html

In the example in section 2.8, the element name should be "item", for consistency with preceding text, and previous examples.

An erratum will be added as proposed above.

Erratum E0-19 added.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0163.html

Various suggestions are made to improve the usability of the table in section 4.4.

Martin will investigate possible ways to improve the format of the table. Also, the last entry of the table should probably indicate that a minOccurs, maxOccurs pair of (1,1) is a valid restriction of (1,1).

Erratum E0-20 added.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0175/.html

Henry's response: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0178.html

This requirement will be passed to the Requirements Task Force to handle, and include in the requirements document.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0182/.html

Part 2 implies they are allowed, but Structures does not.

Henry's response http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0284.html

An erratum will be added that lists the Structures spec changes needed to reflect the additional valid finalDefault values.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0198/.html

Section 3.8.2 permits minOccurs=0 on an "all" element, but 3.7.2 and 3.8.6 (Schema Component Constraint: All Group Limited) prohibit the value from being zero for all uses.

It was the intention that minOccurs=0 should be permitted on an "all" element. Erratum item E1-2 has been created in the Errata doc.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0091/.html

The Datatypes spec states: "A datatype is bounded if its value space has either an inclusive upper bound or an exclusive upper bound and either an inclusive lower bound and an exclusive lower bound." Shouldn't the last "and" be "or"?

An erratum will be added that reflects the proposed change.

Erratum number is: E2-3.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0204/.html

Section 4.1.2.3, definition of {member type definitions} states: "If {variety} is union for any Simple Type Definition components resolved to above, then the that Simple Type Definition is replaced by its {member type definitions}. "

An erratum will be added that corrects the grammatical error.

Erratum number is: E2-1.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0205.html

Section 4.1.2, definition of {final} states:

"A set corresponding to the actual value of the final [attribute], if present, otherwise of the actual value of the finalDefault [attribute] the ancestor schema element information item, if present, otherwise the empty string, as follows: ". Shouldn't "of" be intserted in front of "the ancestor"?

An erratum will be added that corrects the grammatical error. The "of" in "of the finalDefault" should be moved before "the ancestor".

Erratum number is: E2-4.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0207.html

The title is "Canonical Rrepresentation".

The spelling mistake will be corrected in an erratum.

Erratum number is: E2-2.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0208.html

The pargraph beginning with "The CCYY field..." should be changed to: "The CCYY field must have at least four digits, the MM, DD, hh, mm and ss fields exactly two digits each (not counting fractional seconds); leading zeroes must be used if the field would otherwise have too few digits."

An erratum will be added which corrects this typographical error.

Erratum number is: E2-5.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0210.html

Section 4.2.2.1 states: "When {variety} is union, if {value} is true for every member of {member type definitions} and all members of {member type definitions} share a common ancestor, then {value} is true; else {value} is false." But, {value} can be "partial" or "total" but not "true".

An erratum will be added to correct this text.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0215.html

"fragement" should be "fragment".

Erratum number is: E2-6.

An erratum will be added correctly this spelling mistake.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0216.html

The WG has decided the following:

1. The base64Binary type has no line length restriction on its lexical forms. So it's not a type error if the value contains (for example) 800 characters without any newline sequence.
2. The lexical form of base64Binary data can contain any of the 65 characters in the "Base64 Alphabet", plus any characters recognized by the XML spec as whitespace. occur.
3. An erratum will be created to clarify these rules and illustrate the grammar for the lexical and canonical forms of the datatype.

See item E2-9 in the Errata doc.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0217.html

A request for the clarification of how the pattern facet works for list datatypes. Also, the NMTOKENS, IDREFS and ENTITIES types do not list pattern as an acceptable facet.

An erratum will be created to clarify the semantics of pattern for lists (the pattern applies to the whole list). The erratum will also add the pattern facet to the datatypes listed.

Issue also affects Primer - Erratum E0-18 added for Primer.

Proposed datatypes text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0234.html

Reviewed and approved, with ammendments, at Oct. 25 concall.

Erratum E2-30 added.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0223.html

The XML representation for the group element information item, in section 3.7.2, is missing the attributes "ref", "minOccurs", "maxOccurs".

An erratum, E1-3, has been created to correct this.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0219.html

In the example in section 3.4.2 of Structures, the references to types "xs:nonPositiveInteger" and "xs:non-positive-integer" should both be "xs:nonNegativeInteger".

An erratum will be added to correct this.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0209.html

Is the itemType of a list meant to be of "atomic" type ONLY or of EITHER "atomic" OR "union" type? Sections 2.5.1.2 and 4.1.2.2 of Datatypes appear to be contradictory.

It was intended that the itemType be either atomic or union. An erratum will be added to clarify this.

The datatypes spec has some inconsistencies with IEEE with respect to certain special values (such as NaNs). Should it be modified to reflect IEEE semantics?

See http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001May/0030.html

A straw poll was held for the following questions:

• Should bit patterns be allowed to be specified for NaNs?
• Should there be a distinction made between signalling and quiet NaNs?
• Is NaN a value?
• Does NaN compare equal to NaN?
• Should NaNs be comparable to non-NaN values?
• Are -0 and +0 the same value?

The results of the poll were summarized in the following meeting minutes: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Jul/0014.html

No firm decisions made to date.

Status 2002/01: Dave P. and Ashok Malhotra have proposed the following resolution/text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jan/0066.html

Further discussion: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jan/0101.html

The WG resolved that this should be classified as an error, and the editors are to prepare final wording for an erratum that reflects the decisions made at the 02/01 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Feb/0009.html

Proposed erratum text reviewed at the March 28 telecon. The WG noted a possible contradiction in the definition of zero in the erratum for R-22 with our decision on R-97 and concluded that this erratum text is not yet ready, and instructed the editors to deal with R-22 and R-97 in the same erratum.

Status 04/24: New erratum text proposed: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Mar/0131.html

Status 05/02: Revised text approved.

Erratum E2-40 added.

The constraints listed for "derivation-ok-restriction" do not appear to prohibit the following:

<xsd:complexType name="baseType">
     <xsd:attribute name="attrib1" type="xsd:string" use="prohibited"/>
<xsd:complexType>

<xsd:complexType name="restrictedType">
     <xsd:complexContent>
          <xsd:restriction base="baseType">
               <xsd:attribute name="attrib1" type="xsd:string" use="required"/>
          </xsd:restriction>
     </xsd:complexContent>
</xsd:complexType>

Shouldn't this be disallowed, since instances of the restricted type are not valid instances of the base?

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0225.html

This restriction is already disallowed by the Structures spec. In the base type, there is no component for the attribute because of the use="prohibited". Given this, clause 2.2 of Schema Component Constraint: Derivation Valid (Restriction, Complex) applies and causes this example to be invalid.

No erratum is required.

The constraints for "Particle Valid (Restriction)" indicate that pointless occurrences of sequence, all and choice should be ignored. By doing so, it is possible that certain derived types which would otherwise be valid restrictions of their base types, become invalid.

See the following for more information, and an example: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0230.html

Note that Achille Fokoue posted another example illustrating this problem. See the following for more information: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0111.html

Note also that a subsequent email on pointlessness was sent in by Gareth Sylvester-Bradley: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JulSep/0040.html

The WG has discussed various solutions:

• Leave the rules asis.
• Modify the rules for pointlessness to indicate that they "may" apply instead of "must" apply
• define a new algorithm

The WG has decided that although the rules have some awkward results, they are not in error. It will be put on the list of issues to consider for a future revision of XML Schema.

Clause 5.2.2.2 of "Validation Rule: Element Locally Valid (Element)" refers to {content type} in both of its sub-bullets. However, "content type" is defined for complex types only, and the element may have simple type. Should an editorial change be made to correct this?

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0235.html

Discussed at the May 29,2003 telecon.

RESOLVED: classify R-25 as error with erratum

RESOLVED: ask editor to draft a fix to qualify existing cases with "if the actual type definition is complex" and add a new case for "simple"

In section 3.3.5, under the heading Schema Information Set Contribution: Assessment Outcome (Element), in the box labeled "PSVI Contributions for element information items", in item 1.1.3 for "unknown" read "notKnown".

In section 3.3.5, under the heading Schema Information Set Contribution: Element Validated by Type, in the second box of PSVI Contributions for element information items, for "simple thype definition" read "simple type definition".

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0236.html

Proposed text, available at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Aug/0005.html approved at Sept. 13 concall.

Erratum E1-12 added

This is a request for additional information in the Primer in the following areas:

• the default for "use" in section 2.2.1
• using global attributes
• default namespace

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0242.html

This documentation suggestion will be considered by the WG for a future revision of the specification.

In the Structures spec, section 3.3.4 Element Locally Valid (Type), bullet 2 states:

"2 Its {abstract} must be false."

However, the type is not necessarily complex, and "abstract" is not a property of simple types.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0246.html

Discussed at the Apr. 26 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Apr/0084.html.

The WG resolved to classify R-28 as an error and instruct the editor to draft an erratum, saying that the type in question may not have {abstract} = true, rather than saying it must have {abstract} = false)

Proposed text, available at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Aug/0005.html approved at Sept. 13 concall.

Erratum E1-13 added

The Datatypes spec has a request for comments in the appendix describing regular expressions. Should this be removed?

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0251.html

Proposed text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0235.html

Discussed and approved at Oct. 24 telecon.

Erratum E2-31 added.

This is a request for clarification of the semantics of "XmlCharRef" in regular expressions.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0255.html

The WG agreed that the commentator is correct, and that the production for character reference should not be in the grammar.

Alexander Falk proposed the grammar change as part of mail http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Sep/0044.html.

Erratum item E2-18 was revised to incorporate this change.

In the value space of anyURI, are URIs supposed to be absolutized using xml:base?

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0256.html

The WG has agreed that URIs are not to be absolutized.

An erratum, E2-11, has been created that results in changes to 3.2.17 and the bibliographic reference, specifying that we refer normatively only to section 5.4, paragraph 3 of XLink.

The "XML Representation Summary" for notation indicates that the public identifier has a value of type anyURI. But the schema for schemas indicates that the public identifier is of a type derived from token.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0281.html

Discussed briefly at a telecon in 09/2001: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Sep/0017.html.

The WG decided it needed more preparation to determine the answer.

Change made as part of erratum E1-16

Bullet 4.3 of section "Validation Rule: Identity-constraint Satisfied" states:

"If the {identity-constraint category} is keyref, then for each member of the qualified node set (call this the keyref member), there must be a node table associated with the {referenced key} in the [identity-constraint table] of the element information item (see Identity-constraint Table, which must be understood as logically prior to this clause of this constraint, below) and there must be an entry in that table whose key-sequence is equal to the keyref member's key-sequence member for member, as defined by Equal in [XML Schemas: Datatypes]."

Does this mean that the identity constraint referenced by the keyref must apply to the element the keyref is on or to one of its descendants, or may the identity constraint referenced by the keyref appear anywhere at all in the instance document?

If the former, the Primer contains an invalid example. Either way, this rule should be clarified.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0275.html

Henry's response: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0279.html

The WG decided that the Structures spec needs a clarification of this constraint, and that the Primer has an example that is invalid. The commentator's interpretation is correct, namely, that the key or unique identity constraint to which a keyref refers must be within the scope of the element the keyref is on.

Erratum E0-22 added for Primer.

Structures erratum http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0313.html reviewed and approved at the Nov. 1 telecon.

Structures erratum E1-19 added

Section 3.14.6 of Structures states the following for bullet 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).

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.

However, lists and unions have the ur-type definition as a base.

And, shouldn't the following rules be stated?

• If the {variety} is list, then the {final} of the {item type definition} must not contain list.
• If the {variety} is union, then the {final} of all the {member type definitions} must not contain union.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0294.html

Henry's response: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0296.html

The WG determined that the commentator is correct, and bullet 4 of Section 3.14.6 of Structures need to be modified to include the following rules:

• If the {variety} is list, then the {final} of the {item type definition} must not contain list.
• If the {variety} is union, then the {final} of all the {member type definitions} must not contain union.

Proposed text (E1-15) available at: http://www.w3.org/XML/Group/2002/09/xmlschema-1/structures-with-errata.html#coss-st

Revised text : http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Sep/att-0224/01-e1-15.html reviewed and approved at Oct. 3 telecon.

Erratum E1-22 added

Productions [22] and [37] may cause the grammar to be ambiguous.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001AprJun/0245.html

There is an ambiguity. An erratum will be created to fix the problem.

Erratum item E2-10 has been created.

In section 2.5.2 of the Primer, the word "name" in the sentence beginning "Specifically, text appears between the elements..." should be rendered in monospaced font.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0039.html

Erratum E0-17 added.

The link "http://www.iso.ch/markete/8601.pdf" in the datatypes spec does not work.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0045.html

Erratum E2-42 added.

Is there a constraint missing for fractionDigits, indicating that the value in a restriction must be less than or equal to any such value in a base type definition?

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0058.html

The WG has concluded that a constraint needs to be added, but the case where the base type does not specify a value needs to be examined. Paul Biron to review all constraints of this kind to ensure they make sense when the base type does not have a value, and to provide wording to handle such cases.

Initial erratum for this particular case has been proposed:

http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Nov/0039.html

PVB determined that no further errata was required.

The DTD for Schemas is missing the optional annotation child of extension.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0059.html

Paul also pointed out that the same problem occurs for simpleContent and complexContent.

The WG agreed that the DTD for Schemas should be modified to include an optional annotation child for extension, simpleContent and complexContent.

Erratum item E1-4 has been created.

A request to add text to the appendix for regular expressions to clarify the matching algorithm and to indicate that implicit anchoring occurs for patterns.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0064.html.html

The WG agreed with the commentator that such a clarification should be made.

Final proposed text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0243.html reviewed/approved at Oct. 24 telecon.

Erratum E2-32 added.

Production 10 should be modified to consider brace brackets as metacharacters.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0063.html

The WG agreed that the grammar should be modified as per the description above.

Alexander Falk proposed the grammar changes in message http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Sep/0044.html.

The particle derivation rules for "RecurseLax" appear to prohibit the following type derivation. Was this intentional, or should the rules be modified to permit such a derivation? The mail below suggests a possible modification of the rules.

<xs:complexType name="B">
 <xs:choice minOccurs="1" maxOccurs="1">
  <xs:group minOccurs="0" maxOccurs="1" ref="ChoiceGroup"/>
  <xs:element name="e"/>
 </xs:choice>
</xs:complexType>

<xs:complexType name="derived">
 <xs:complexContent>
  <xs:restriction base="xs:B">
   <xs:group minOccurs="0" maxOccurs="1" ref="ChoiceGroup"/>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>

<xs:group name="ChoiceGroup">
 <xs:choice>
  <xs:element name="e2"/>
  <xs:element name="e3"/>
 </xs:choice>
</xs:group>

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0035.html

As per issue R-24, the WG has decided that although the rules have some awkward results, they are not in error. The issue will be added to a list of items to consider for a future revision of XML Schema.

Table 1 of the Primer shows some examples that contain default values for elements/attributes. The text in the "Notes" column should reflect the different semantics that occur for elements/attributes; as currently written, it could be misinterpreted.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0053.html

Also see: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0114.html

Proposed erratum available at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Aug/0010.html

Text approved as ammended at Sept. 13 concall.

Erratum E0-29 added.

In the paragraph following the first example of section 5.6 of the Primer, "... where to find to an appropriate ..." should be "... where to find an appropriate ...". Also, the commentator suggests a rewording of the description of the schemaLocation attribute.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0076.html

Proposed erratum available at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Aug/0010.html

Text approved at Sept. 13 concall.

Erratum E0-28 added.

In Section 5.5 of the Primer, references to "HTML" should be "XHTML".

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0078.html

Erratum E0-16 added.

Section 3.11.1 of Structures, the schema component definition for identity constraints states that {fields} is a list of restricted XPath expressions, and that {selector} is a restricted XPath expression.

Section 3.11.2, the XML representation for <field> and <selector> allows an <annotation>. There is no schema component to which this annotation can adhere.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0079.html

Tentative resolution: http://www.w3.org/XML/Group/2001/10/xml-schema-ftf-minutes#ab1b3b3b3b1b2

An erratum will be created specifying promotion, and the issue will be included in the candidate list of items to consider for 1.1

Proposed erratum, included in the following http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Aug/0005.html was approved at the Sept. 13 concall.

Erratum E1-14 added

Constraint 5.3 of "Schema Component Constraint: Derivation Valid (Restriction, Complex)" states:

"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)."

Does the use of the definite article in the phrase "the particle of the {content type} of the {base type definition}" imply that the {content type} must have a particle, and must not be empty? If not, what prohobits the following:

  <xs:complexType name="rrr" />
  <xs:complexType name="sss">
    <xs:complexContent>
      <xs:restriction base="rrr">
        <xs:sequence>
          <xs:element name="dummy"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0081.html

Tentative resolution: http://www.w3.org/XML/Group/2001/10/xml-schema-ftf-minutes#ab1b3b3b3b1b3

The WG approved the tentative resolution above. An erratum will be created clarifying that the example is in error not because of constraint 5.3, but because of failure to match particles in one against the other.

Proposed erratum available at: http://www.w3.org/XML/Group/2002/09/xmlschema-1/structures-with-errata.html#derivation-ok-restriction

Sept. 20: RESOLVED: to accept E1-17 as amended (s/from a/by restricting a/).

Erratum E1-15 added.

There appears to be a discrepancy between the lexical representation of gMonth in the "XML Schema: Datatypes" recommendation and the truncated representation of a month described in 5.2.1.3 of ISO 8601:1988. The former indicates that the lexical representation is "--MM--", while the latter specifies the truncated representation as "--MM".

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0094.html

The WG has agreed this is an error.

Errata E0-15 and E2-12 added.

ISO 8601:2000 defines 0000 to be a valid year, unlike the specification of dateTime in the "XML Schema: Datatypes" recommendation. Should dateTime follow ISO 8601:2000 in this respect?

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0095.html

See:

http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0098.html

http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0100.html

http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0101.html

Recent discussion: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0042.html

The Primer shows the application information element as <appInfo> while Structures defines it as <appinfo>.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0104.html

Tentative resolution: http://www.w3.org/XML/Group/2001/10/xml-schema-ftf-minutes#ab1b3b3b3b1b4

The Structures spec is correct. The editor will create an erratum for the Primer.

Erratum E0-14 added.

Section 2.3 of the Primer, paragraph 3 states:

"Suppose we wish to create a new type of integer called myInteger whose range of values is between 10000 and 99999 (inclusive). We base our definition on the built-in simple type integer, whose range of values also includes integers less than 10000 and greater than 99999."

The second sentence should read:

"We base our definition on the built-in simple type integer, whose range of values also includes integers greater than or equal to 10000 and less than or equal to 99999."

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0108.html

The commentator misunderstood; the Primer is correct.

Constraint 3 of "Schema Representation Constraint: Attribute Group Definition Representation OK" prohibits direct circular attribute group references, but doesn't appear to prohibit indirect circular references.

See Issue 1 from the following mail: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0121.html

Tentative resolution: http://www.w3.org/XML/Group/2001/10/xml-schema-ftf-minutes#ab1b3b3b3b1b5

The WG resolved that the constraint (at the component level) needs to be added. Erratum pending.

Proposed text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0184.html reviewed and approved at Oct. 11 telecon.

Erratum E1-20 added

Assuming schema document A includes schema documents B and C, where B has the same target namespace as A, and C has no target namespace. Which components may be referenced from any given component in A, B or C?

In particular, given the following table (where R(A,B)=Y means components in A may refer to components in B), what should the table entries be for any marked "?".

R A B C
A Y Y Y
B ? Y ?
C ? ? Y

From the spec, it appears that components in B may refer to components from A (see bullet 4 of QName resolution (Schema Document)). Is this correct? What about the other cases?

See Issue 3 from the following mail: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0121.html

The WG agreed that all three documents contribute components to and resolve their references in the single target namespace, so all cells in the table should be 'Y'.

Given the following definitions from the Structures spec:

"[Definition:] A distinguished ur-type definition 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."

and

"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 types, this is the simple version of the ur-type definition, whose name is anySimpleType."

Then:

1. Is the ur-type one type or two types?

   From the first paragraph, the ur-type appears to be one type, with the name anyType. But from the second paragraph, anySimpleType is a version of the ur-type. Does this mean that ur-type is a group of types, which includes both anyType and anySimpleType?

2. Is it "ur-type" or "anyType" that can function as a complex or a simple type definition? Or both?

   If "anyType" can act as a simpleType, then is the following valid?

   <attribute name="att" type="anyType"/>
   

   Or is anyType considered to be the "complex version" of the ur-type definition, and it can only act as a complex type?

See Issue 2 from the following mail: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0121.html

Proposed response from Henry Thompson (to be discussed within WG): http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jan/0065.html

Discussed and resolved at the Feb. f2f. Henry Thompson to draft erratum reflecting his proposal (see above). Paul Biron to check the datatypes spec for potential changes.

Discussed at several concalls.

Final proposed erratum http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Nov/0004.html was approved (assuming an amendment to the S4S) at the Nov. 7 concall.

Erratum E1-22 added

Table 2 of the Primer shows the following as examples of unsignedByte:

0, 126

"0, 256" was likely intended, as "256" is the upper bound for this type.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0122.html

Erratum E0-13 added.

The last sentence in section 2.5.2 of the Datatypes spec contains the following:

"or 3) by creating a union datatype whose value space consists of the union of the value space its memberTypes. "

Change "the value space" to "the value spaces" and insert "of" before "its".

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0130.html

Section 2.1 of Structures contains:

"Schema-validity assessment has two aspects:
1 determining local schema-validity ...
2 Synthesizing an overall validation outcome for the item ..."

The words "determining" and "Synthesizing" should be capitalized consistently.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0137.html

Erratum E1-42 added.

1. The root element name in the DOCTYPE declaration (PurchaseOrder) does not match the root element name in the instance (purchaseOrder)
2. The "orderDate" attribute value specification on the "purchaseOrder" tag is not terminated with a ".

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0144.html

Erratum E0-12 added.

Various suggestions are made, including:

1. using the word "resolved" instead of "dereferenced" in the text that states "...the entity will be dereferenced before schema validation."
2. rewriting the "city" element so that the empty element tag is not used.

See the following for more information: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0145.html

Proposed erratum available at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Aug/0010.html

The first 2 changes in the erratum were approved at the Sept. 13 concall

Erratum E0-27 added.

The elt derived from choice case of particle restriction checking rules out the derivation of the type of <xs:all> from <xs:explicitGroup> in the Schema for Schemas.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0172.html

The WG resolved that the Schema for Schemas is in error; Henry Thompson to prepare an erratum.

Proposed text at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Apr/0074.html

Errata approved at May 2 concall.

Errata added as E1-8

Section D.3.1 states: "An optional minus sign is allowed immediately preceding, without a space, the lexical representations for duration, dateTime, date, gMonth, gYear."

Shouldn't "gMonth" be "gYearMonth"?

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0178.html

Proposed errata text available at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Apr/0050.html

Errata approved at May 2 concall (on condition that the ins/del text be made more specific)

Erratum E2-19 added to the errata doc.

Is whitespace allowed in Identity Constraint XPath expressions?

The BNF in the XML Schema REC doesn't mention whitespace. Neither does the equivalent BNF in XPath. But elsewhere in XPath it says whitespace is allowed almost anywhere.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0183.html

Whitespace should be permitted in XPath expressions. An erratum will be created to reflect this.

Proposed erratum approved at the March 28 telecon.

Erratum added as item E1-6.

The definition of the "maxOccurs" attribute and its type is used to illustrate unions in section 2.5.1.3. For completeness, the attribute declaration should probably contain "default=1".

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0191.html

Proposed text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/att-0315/01-errataR-63.html reviewed/approved at Nov. 1 telecon.

Erratum E2-33 added.

The complexType mapping rules state that types without children have content type empty, even if mixed is specified.

See the following for some derivation examples that exhibit this:

http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Apr/0016.html

The following is an additional example, without an explicit derivation that illustrates the issue:

<complexType name="foo" mixed="true">
</complexType>

Given the mapping rules in Structures, the type above will have content empty, and not mixed.

Henry's response: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Apr/0018.html

The WG has resolved to classify this as an error in the Structures spec. Henry to propose erratum.

April 11: proposed erratum text approved.

Erratum added as E1-7.

1. The rules for "Schema Component Constraint: Attribute Wildcard Union" have the following problems:

   • Various references to "intersection" in this section should be "union".
   • Bullet 4 gives the rule for "...the two are negations of different namespace names..." and indicates the result in not expressible, but in fact is.

   See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001May/0027.html

   Henry's response: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Jun/0017.html

2. In addition, in a separate email, the commentator points out a problem with wildcard subset, "##other" and absent. For example, if wildcard "w2", say, equals "absent", and wildcard "w1" is "not some-uri", then, "absent" is allowed by "w2", not allowed by "w1", and yet the rules for subset indicate that "w2" is a subset of "w1". See:

   http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Jun/0028.html

   Henry's response: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Jun/0011.html

As a result of these exchanges, the commentator proposes the following modifications to wildcard union, subset and intersection:

http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Jun/0028.html

The WG has agreed that the commentator has uncovered errors in the Structures spec. Henry to prepare wording of an erratum.

Proposed text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002May/0157.html

Final text approved at the June 28 concall.

The Datatypes spec states:

'The value space of ENTITY is the set of all strings that match the NCName production in [Namespaces in XML] and have been declared as an unparsed entity in a document type definition.'

The commentator asserts that ENTITY is not a primitive datatype and that a processor need not enforce 'have been declared as an unparsed .. '. A request is made to clarify this.

A similiar issue is raised for ENTITIES.

See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Jun/0005.html

Discussed at the Oct. 25 concall: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Oct/0054.html

The WG resolved to classify this as an error, and instruct the editors to prepare an erratum.

Status 2002/02: Draft erratum proposed by Paul Biron: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Feb/0014.html

Further discussion of the erratum at the f2f: http://www.w3.org/XML/Group/2002/02/xml-schema-ftf-minutes.html#ab2b3b3b5c13

Further discussion at the March 28 telecon. Datatypes erratum approved. HST to prepare corresponding errata text for the Structures document, formulating the constraints which are no longer part of simple type validity.

Proposed Structures errata http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0313.html was reviewed and approved with ammendments at the Nov. 1 telecon.

Erratum E1-18 added

Schema Component Constraint: Type Derivation OK (Simple) lists conditions under which a simple type D is considered to be validly derived from another simple type B. The first condition is:

"1 They are the same type definition."

Is possible for 2 anonymous simple type definitions to be considered "the same type definition"?

See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Jun/0010.html

Henry's response: No, but the REC isn't completely clear about this. Clause 1 above could probably usefully be changed to read "They are the same named type definition". See:

http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Jun/0012.html

Further email and thoughts from Henry: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Nov/0037.html

Status 2002/01: Henry to propose a resolution/text.

Status 2002/02: Proposed resolution and follow-on email from Henry:

http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Feb/0013.html

http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Feb/0027.html

Resolved at the Feb. f2f. Henry Thompson to draft erratum reflecting his original proposal (see above). And, the issue of identity and anonymous types should be considered for 1.1.

Also, an example in the Primer needs to be modified.

Primer erratum E0-21 added.

Proposed text at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/att-0221/00-R-67etc.html

Discussed and approved at Oct. 24 telecon http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0248.html

Structures erratum E1-17 added

There appears to be a contradiction in Structures as to whether a complexType with simpleContent is allowed to be derived by restriction from a mixed type.

The property mapping rules for complex type with simple content state the following for content type when restriction is chosen:

"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 a simple type definition, see below) and the restriction alternative is chosen ...".

In addition, Schema Representation Constraint: Complex Type Definition Representation OK states:

"If the <simpleContent> alternative is chosen, the type definition resolved to by the actual value of the base [attribute] must be either a complex type definition whose {content type} is a simple type definition or, only if the <extension> alternative is also chosen, a simple type definition; "

However, "Schema Component Constraint: Derivation Valid (Restriction, Complex)" states:

"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).

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

See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Jun/0047.html

Henry's response http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Jun/0050.html

Further discussion at the Dec f2f: http://www.w3.org/XML/Group/2001/12/xml-schema-ftf-minutes.html#ab1b3b3c11b2

Status 01/2002: Discussion to be postponed until after R-54 is resolved. See minutes: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jan/0080.html

Discussion resumed on April 16: http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2002Apr/0022.html

Resolved at the May f2f. The WG decided to instruct the editor to draft erratum, correcting any text which conflicts with 5.1.2 above.

Draft errata posted at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0201.html

Discussed and approved at Oct. f2f. See: http://www.w3.org/XML/2002/10/xml-schema-ftf-minutes

Erratum E1-27 added.

The definition of a Character Range includes EBNF grammar rules [17] to [22] and some prose, which says:

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; and
• The - character is a valid character range only at the beginning or end of a positive character group.

The last item contradicts production [17] of the grammar.

See http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Sep/0045.html

Discussion at the Dec f2f: http://www.w3.org/XML/Group/2001/12/xml-schema-ftf-minutes.html#ab1b3b3c11b3

Paul Biron to propose erratum text.

April 11: WG approved erratum text, with minor modifications.

Primer erratum E0-11 added. Datatypes erratum E2-18 added.

The id attribute of the unsignedByte type definition is wrong:

<xs:simpleType name="unsignedByte" id="unsignedBtype">

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0216.html

Erratum E2-29 added.

In Element Declarations Consistent, name -> {name} and target namespace -> {target namespace} in clauses (1 and 2) and 3 respectively.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0218.html

Erratum E1-28 added

In Appendix E of http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#component-diagram in the Element declaration rectangle,"substitution group affliation" should be "substitution group affiliation". An "i" is missing.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JulSep/0221.html

The {attribute uses} property for an Attribute Group Definition schema component is defined as:

"The union of the set of attribute uses corresponding to the <attribute> [children], if any, with the {attribute uses} of the attribute groups resolved to by the actual values of the ref [attribute] of the <attributeGroup> [children], if any."

When performing the union operation, are duplicate attribute uses included in the final set? For example, consider the following:

 <xsd:attributeGroup name="fred" >
      <xsd:attributeGroup ref="bas:bill"/>
      <xsd:attributeGroup ref="bas:bill"/>
 </xsd:attributeGroup>

 <xsd:attributeGroup name="bill">
      <xsd:attribute name="bob" type="xsd:string"/>
 </xsd:attributeGroup>

When we compose the "set" of {attribute uses} for fred, should we only include the attribute use for "bob" once? Or does the final set of {attribute uses} contain 2 duplicate attribute uses for "bob" and result in an error according to constraint 2, section 3.6.6?

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0003.html

The WG decided (at the 12/20/2001 telecon) that the example is in error. An erratum will be created to clarify what it means to do the union operation to obtain the final {attribute uses}.

There doesn't appear to be a constraint prohibiting circular substitution groups.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0018.html

An erratum will be created to include a constraint prohibiting circular substitution groups.

Proposed text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0175.html reviewed at Oct. 11 telecon. Approved with suggested ammendments (see meeting minutes for details).

Erratum E1-23 added

The following example is invalid according to the definition of maxExclusive, which states that "The value of maxExclusive must be in the value space of the base type":

 <xs:simpleType name="foo">
   <xs:restriction base="xs:float">>
    <xs:maxExclusive value="5"/>
   </xs:restriction>
 </xs:simpleType>
 
 
 <xs:simpleType name="bar">
   <xs:restriction base="foo">
    <xs:maxExclusive value="5"/>
   </xs:restriction>
 </xs:simpleType>

Should the example be valid if "fixed" is specified for maxExclusive in the base?

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0041.html

At the 12/20/2001 telecon, the WG decided to treat R-75 as an error and to instruct the editor to change the text to specify that the value of maxExclusive must be in the value space of the base type, or else the same value as the effective maxExclusive facet of the base type (if any).

April 5: proposed erratum approved by WG.

Erratum E2-39 has been added to the errata doc.

The {content type} of the following type is EMPTY, according to the rules for determining {content type} for complex types:

   <complexType name="foo">
     <sequence>
     </sequence>
   </complexType>

However, it doesn't appear that the {content type} of either of the following examples is EMPTY according to these rules. Have I understood the rules correctly, and was this intended?

   <complexType name="bar">
     <sequence>
       <sequence>
       </sequence>
     </sequence>
   </complexType>

   <complexType name="bob">
     <sequence>
        <element name="a" minOccurs="0" maxOccurs="0"/>
     </sequence>
   </complexType>

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0044.html

The WG decided (at the 01/03/2002 telecon) that the commentator interpreted the rules correctly and they were in fact intended. Also, it should be noted, that there are different validation semantics for elements of type "foo" and "bar".

An XPath expression that selects elements or attributes in a particular namespace must use prefixes associated with that namespace. If you want to use identity constraints in a chameleon schema, then, the XPath expression must be modified to use prefixes which are associated with the target namespace of the including schema.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0047.html

The WG decided (at the 01/03/2002 telecon) that R-77 should be included in the list of problems to consider for 1.1, with a view toward improving things. Also, the editor will create an erratum to highlight this in the Structures spec.

Consider the following example:

<element name="e1" block="substitution"/>
<element name="e2" substitutionGroup="s:e1"/>

<complexType name="t">
<choice>
  <element ref="s:e1"/>
  <element ref="s:e2"/>
</choice>
</complexType>

The choice violates the constraints for UPA, because "e2" is in "e1"'s substitution group. However, "e2" can never substitute "e1".

Should the definition of substitution group (Schema Component Constraint: Substitution Group) be modified?

See bullet 1 from: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0049.html

See the discussion from the 01/03/2002 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jan/0006.html

Further discussion at the 01/24/2002 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jan/0082.html

The WG resolved to classify R-78 as an error, and instruct the editor to draft an erratum, defining substitution group not recursively as now but using a formulation similar to that of 3.3.6 Substitution Group OK (Transitive), while not changing other constraints (such as the requirement that the data types of the two elements stand in a particular derivation relation). See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jan/0101.html

Proposed text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0175.html reviewed at Oct. 11 telecon. Approved with suggested ammendments (see meeting minutes for details).

Erratum E1-23 added

In various places in the Structures spec, statements like the following appear:

"type definition A must be validly derived from type definition B given its {prohibited substitutions}, as defined in Type Derivation OK (Complex) (213.4.6) (if it is a complex type definition), or given the empty set, as defined in Type Derivation OK (Simple) (213.14.6) (if it is a simple type definition)."

Questions:

1. Which type does each reference of "it" refer to in the paragraph above?
2. There is no constraint for the case where A is a simple type and B is a complex type; how do we check whether the type "string" is a valid derivation from "anyType"?

See bullet 2 from: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0049.html

The WG resolved to classify R-79 as an error, at the March 14 telecon

There is contradictory definition of the meaning of ##other in the Rec Draft of XML Schema. One section indicates that any attribute/element from any namespace other than the target namespace is valid, including absent namespace. Another section specifies that a valid attribute/element must be namespace qualified. So is the absent namespace valid or not?

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0052.html

Henry confirmed that absent is not included. Note that a related issue was raised in R-65.

Henry to draft erratum correcting the text in section 3.10.1.

Proposed text approved at the June 28 concall.

Primer erratum E0-10 added. Structures erratum E1-11 added.

There is an error in the example of section 5.1 of the Primer (entitled "A Unique Composed Value"):

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

The rules of identity constraints say that the field xpath should only return one node for each node selected by the selector [1]. In this case, an r:zip can contain many r:parts, each with their own number attribute. This violates the rule.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0055.html

The WG agreed that the commentator was correct.

Priscilla proposed the following erratum to the WG: http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2002Jan/0050.html

New proposed erratum available at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Aug/0010.html

Text approved at Sept. 13 concall.

Erratum E0-26 added.

The commentator points out editorial errors in sections 2.3.1, 5.1 and 5.2.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0059.html

Errata E0-7,8,9 added.

The "token" datatype should exclude #xD (in addition to #xA) in the lexical and value space.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0064.html

Discussed at the Feb. 7 concall: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Feb/0017.html

The WG resolved that the commentator is correct; Datatypes editors to draft an erratum.

March 28: erratum approved and to be added to errata doc.

Erratum E2-17 added to errata doc.

The Datatypes rec and the Schema for Datatypes do not allow the value "extension" for the final attribute of a simpleType.

However, section 3.4.6 of the Structures rec (under Derivation Valid (Extension)) says:

2 If the {base type definition} is a simple type definition, then all of the following must be true:

• 2.1 The {content type} must be the same simple type definition.
• 2.2 The {final} of the {base type definition} must not contain extension.

It seems that 2.2 will always be true. Is this an oversight?

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0067.html

See: http://lists.