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.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0068.html

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

The Datatypes spec is not clear about the interpretation of QNames without prefixes. There is simply a reference to the XML Namespaces spec.

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

Henry's response:

This should be clarified in the REC -- the intention is that unprefixed names are qualified iff there is a default namespace declaration in scope, i.e. as per element names, not attribute names, in XML 1.0 plus Namespaces.

The definition should also make clear that the value space includes pairs of "no known namespace", local name, which correspond to unprefixed QNames when no default declaration is in scope.

Henry Thompson to draft erratum text reflecting discussion above.

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

This is a duplicate of rec issue R-101, and will be closed when R-101 is closed. See R-101 for more details.

Should the following description in XML Representation Summary: complexType Element Information Item be changed from:

"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 and of the base wildcard, as defined in Attribute Wildcard Union (213.10.6)."

to:

"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 complete wildcard and of the base wildcard, as defined in Attribute Wildcard Union (213.10.6)."

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

Henry's response: Yes.

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-87 as an error and instruct HST to draft erratum for R-87 substituting "complete wildcard" for "effective wildcard" in XML Representation Summary: complexType Element Information Item.

Erratum E1-30 added.

The commentator suggests:

• Adding a note to the description of NOTATION stating that for compatability, qualified QNames should not be used in the lexical space
• Changing the definition of the lexical space of NOTATION from:

  "The lexical space of NOTATION is the set of all names of notations declared in the current schema."

  to:

  "The lexical space of NOTATION is the set of all QNames of notations declared in the current schema."

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

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

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

Errata will be created to:

1. change the definition of the lexical space to use "QNames" instead of "names" as suggested
2. add a compatability note as suggested

April 5: The WG reviewed the proposed erratum text and decided it needed to be revised to describe a smaller value space, and modify the compatibility note.

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

Reviewed at Nov. 1 telecon. Approved with ammendements.

Erratum E2-34 added.

According to section 3.13.1, "integer is derived from decimal by fixing the value of fractionDigits to be 0." But a decimal with fractionDigits of 0 can still have a trailing decimal point (see section 3.2.3.1). However, the Lexical representation of integer described in section 3.3.13.1 doesn't mention that a trailing decimal point is permitted.

Does 3.3.13.1 implicitly describe an additional pattern facet that is also applied to the decimal datatype in deriving the integer datatype, or is 3.3.13 intended to be a complete description, while 3.3.13.1 is intended to be expository in nature?

According to section 3.3, "the complete definitions of the built-in derived datatypes are provided in Appendix A." But the definition for integer that appears in the Schema for Datatype Definitions in Appendix A does not prohibit a trailing decimal point from appearing on an integer value through an additional pattern facet. Given this, is 3.3.13.1 in error?

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

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

The WG resolved that a trailing decimal point is not permitted, and the editors will draft an erratum changing the schema for schemas, adding a pattern facet to the derivation of integer.

April 5: the WG reviewed proposed erratum text and decided that it needed to be revised to add a replacement for the first sentence of section 3.3.13.

See proposed text at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Sep/0121.html

Sept. 26 concall: RESOLVED: approve the correction for R-89 as drafted.

Erratum E2-43 added.

Sections 3.2.7.1 and 3.2.7.2 of the Datatypes Recommendation define the lexical and canonical representations of the dateTime datatype, respectively. Section 3.2.7.1 states, in part that:

"Additional digits can be used to increase the precision of fractional seconds if desired i.e the format ss.ss... with any number of digits after the decimal point is supported. To accommodate year values greater than 9999 additional digits can be added to the left of this representation."

Questions:

• Unlike the definition of decimal (3.2.3), this definition doesn't specify the minimum number of additional year digits nor the minimum number of additional digits in the fractional portion of the seconds that needs to be supported by a processor. Does a processor really need to be prepared to handle an arbitrary number of digits? Obviously this can have a significant effect on an implementation.
• ISO 8601 specifies that 24:00:00 of one day is the same as 00:00:00 of the following day. Which is the permitted form in the canonical representations of the various types?

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

Ashok's response: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0125.html

1. The WG agreed that the minimum number of digits needs to be specified.
2. The WG agreed that a canonical form needs to be chosen for "24:00:00" for the various types.

Proposed errata text for the 2 issues:

http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2002Jan/0038.html

http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2002Jan/0039.html

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

Further discussion of the decisions to be made for the text launched on the ig list: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Feb/0046.html

Further discussion at the Apr. 11 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Apr/0025.html

The only remaining issue to be resolved is item 5 from list of questions.

Status 06/28: Discussed at length at the June 14, 20 and 28 concalls. No consensus was reached. Latest discussion and summary of open issues can be found at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jul/0004.html

Discussed and resolved at the July f2f http://www.w3.org/XML/Group/2002/07/xml-schema-ftf-minutes.html#ab3b3b3b5

Paul Biron to produce errata text.

Discussed again at the Oct. 25 telecon. WG resolved that the minimum number of digits to be supported is 3.

Ashok drafted some text - see: http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2003May/0028.html

Part of the proposed text, i.e. the conformance note, was approved at the May 23,2003 telecon. Additional text, describing behaviour when a processor receives more digits than it supports is still pending approval.

The extension variant of group redefinition:

• allows pre-extension
• doesn't actually require extension since the self-reference can appear in a choice or optional sequence

The commentator suggests that the semantics be modified to match those of type extension.

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

A model group definition which contains within it an anonymous complex type definition which itself references that very group is allowed:

<xs:group name="list">
 <xs:sequence>
  <xs:element name="item">
   <xs:complexType>
    <xs:sequence>
     <xs:element name="value"/>
     <xs:group ref="list" minOccurs="0"/>
    </xs:sequence>
   </xs:complexType>
  </xs:element>
 </xs:sequence>
</xs:group>

Attempting to redefine such a group by extension is impossible, because of clause 6.1 of Schema Representation Constraint: Redefinition Constraints and Semantics.

A clarification stating that the references checked are those within the content model as such, not within types embedded therein, should be made.

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

The following derivation is valid:

<xs:complexType name="D">
   <xs:complexContent>
     <xs:restriction base="B">
       <xs:anyAttribute namespace="urn:foo" processContents="skip"/>
     </xs:restriction>
   </xs:complexContent>
</xs:complexType>

but D is not a subset of B.

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

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

In the section titled 'Schema Component Constraint: Particle Restriction OK (Elt:Elt -- NameAndTypeOK)', the following is mentioned:

"For an element declaration particle to be a valid restriction of another element declaration particle all of the following must be true:

5 R's declaration's {identity-constraint definitions} is a subset of B's declaration's {identity-constraint definitions}, if any."

The issues are:

1. the spec should be clarified to state what "subset" means
2. the subset requirement runs the wrong way -- the derived element's IC's should be a _super_set of the base's.
3. an element decl in a restriction can't have the same ICs as its corresponding decl in the base, because that would violate the named-components-are-unique constraint

The original questions were posted to the schema-dev list. Henry summarized the issues in the following mail on schema-comments: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0187.html

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

See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jan/0072.html

Henry Thompson will create an erratum that highlights the current limitations (see bullet 3 above). The WG may revisit this issue in a future specification.

This is a request that the WG produce the Primer as a PS or PDF file.

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

This will be added to the list of requirements for a future revision of the specification.

An attribute declaration may be local to an attribute group definition, in which case its scope is specified as *absent*.

But when the group is referenced in a complex type definition, the spec doesn't specify that it's scope is set to that of the complex type.

There may be a similar problem for elements/element groups as well.

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

Resolved at May f2f as an error. Editor is instructed to draft erratum that repairs the limitations imposed by the spec, and to do so for elements and elementGroups as well.

The existing text for the canonical representation for float/double reads:

Specifically, the exponent must be indicated by "E". Leading zeroes and the preceding optional "+" sign are prohibited in the exponent. For the mantissa, the preceding optional "+" sign is prohibited and the decimal point is required. For the exponent, the preceding optional "+" sign is prohibited. Leading and trailing zeroes are prohibited subject to the following: number representations must be normalized such that there is a single digit to the left of the decimal point and at least a single digit to the right of the decimal point.

The problem is that the single digit to the left of the decimal point is allowed to be zero. This allows 1.0E1, 0.1E02 and 0.01E3 etc. as legal canonical representations for the same number.

See the following for a suggested resolution: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0214.html

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

The WG agreed that this is an error. Datatypes editors to draft erratum similiar to what was proposed in the email.

Status 04/24: Erratum text has been proposed as part of the text for issue R-22

The lexical representation of a QName has the form "prefix:localpart" (or "localpart"), and the value of a QName is a tuple {namespace, localpart}. How is a QName value converted to its canonical representation?

This problem occurs when a default/fixed attribute/element value is of type QName. In this case, how is it applied to the instance? For example:

<attribute name="att" type="QName" xmlns:p1="my_uri" default="p1:local"/>

If the above attribute doesn't appear in an instance, we should add a new attribute. But what would be the (string) value of the added attribute? (Note that the prefix "p1" might not be declared in the instance, or it's possible to be bound to a different namespace uri.)

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

See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jan/0080.html

The WG agreed that this is an error, will attempt to come up with a fix for 1.0, and will definitely add it to the list of issues to consider for 1.1. In addition, the datatypes editors will work on text which augments "Validation Rule: Datatype Valid" in section 4.1.4, indicating that the lexical form must map to a value.

According to the Schema for Schemas, the above types are defined as a restriction of another list type, by specifying a "minLength" facet. Then the following simple type:

<simpleType name="mylist">
  <restriction base="NMTOKENS">
    <length value="3"/>
  </restriction>
</simpleType>

is invalid according to the constraint "Schema Component Constraint: length and minLength or maxLength". Is this what was intended? If so, it'd be very inconvenient: the user has to specify both minLength and maxLength to the same value to achieve the result.

To solve this problem

1. Don't include a "minLength" facet in the above 3 types. But this means empty lists are allowed by these types (which might not be proper); or
2. Allow "length" to be specified even if "min/maxLength" are specified on the base type, as long as base.minLength <= length <= base.maxLength.

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

At the March 8 telecon, the WG decided to classify this as an error.

April 5: The WG decided that the proposed erratum text needed to be revised to add the required constraints for the cases where length and one or more of minLength and maxLength are specified in the same derivation chain.

Revised text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0357.html reviewed/approved at Nov. 1 telecon.

Erratum E2-35 added.

The definition of overlapping in appendix H states:

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

Shouldn't it state:

"They are both element declaration particles one of which has the same name and target namespace as an element declaration in the other's substitution group."

Consider the following declarations:

<element name="e1"/>
<element name="e2" substitutionGroup="e1"/>

<choice>
  <element ref="e1"/>
  <element name="e2" form="qualified"/>
</choice>

"e2" in the choice is not in the substitution group of "e1" (because "e2" is locally declared). But the example above still violates UPA, because for an element "e2", we don't know which particle to use for validation.

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

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

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

The WG agrees with the commentator's proposed changes. Henry to draft erratum.

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

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

Erratum E1-31 added

Does the following choice violate UPA?

   <group name="grp">
     <sequence>
       <element name="e"/>
     </sequence>
   </group>
 
   <choice>
     <group ref="grp"/>
     <group ref="grp" maxOccurs="3"/>
   </choice>

"Schema Component Constraint: Unique Particle Attribution" states:

A content model must be formed such that during validation of an element information item sequence, the particle 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.

In the constraint above, what does "particle ... can be uniquely determined" mean?

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

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

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

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

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

http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001OctDec/0077.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 example given does violate UPA, and the text quoted merits clarification. Henry to propose erratum.

Proposed erratum: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/att-0313/01-R-101etc.html

Erratum reviewed/approved at the Nov. 1 telecon.

There doesn't appear to be anything in the REC which blocks a simple type definition of {variety} 'list' whose {item type definition} is not derived from its {base type definition}'s {item type definition}. The same is true for {variety} 'union' and {member type definitions}.

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

Resolved at the March 14 telecon to classify R-102 as an error with erratum and to instruct HST, PVB, AM to prepare erratum text (the text will apply to Structures, but the Datatypes editors have a strong interest here).

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

Erratum E1-24 added

The acronym PSVI isn't expanded anywhere in the Structures spec.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0030.html

Proposed text http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0313.html discussed and approved at Nov. 1 telecon.

Erratum E1-32 added

The commentator asks whether Primer table B is correct in listing fractionDigits as a facet for integer.

David Fallside's response: For integers, fractionDigits = 0, hence the integer listing in Table B1.b would be clearer if integer is not listed as having a fractionDigits facet.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0089.html

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

Resolved at the May f2f to instruct the editor to change the text in the cell.

Erratum E0-23 added.

The commentator points out that, although they're not declared at the top level, Identity Constraints are all in a single namespace and they should have a {identity constraints} property in the Schema component just like all the other globally named things.

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

Resolved at the May 29, 2003 telecon to classify R-105 as 1.1 candidate requirement.

As a result of a discussion of requirement RQ-16, reclassified as error with erratum on the telcon of 26 June 2003. This decision was reconfirmed, and the link to requirement RQ-133 was reasserted, at the face to face meeting of July 2003. Henry Thompson to draft erratum.

QName allows the following facets: length, minLength, maxLength, pattern, enumeration, whiteSpace.

The validation rules for length, minLength, and maxLength facets in 4.3.1.3, 4.3.2.3, 4.3.3.3 --when it comes to atomic variety-- are defined only for Strings and hex/base64Binary.

Questions:

1. Do those three facets apply to the lexical or value space? If the latter, then how? The same question applies to NOTATION and anyURI (considering encoding) types.
2. The other three facets (pattern, enumeration, whiteSpace) seem to apply to the lexical space. Is this correct?

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

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

Re: question 1, the WG resolved:

• to classify R-106a (length of QNames) as clarification w/ erratum, to specify in the erratum that tests on these facets for this type always succceed, and to deprecate the use of these facets for this type.
• to classify R-106b (length of NOTATION) as clarification w/ erratum, to specify in the erratum that tests on these facets for this type always succceed, and to deprecate the use of these facets for this type.
• to classify R-106c (length of anyURI) as clarification w/ erratum and to specify in the erratum that length is measured as the number of characters in the value (which as it happens is the same as the number of characters in the lexical form).

No resolution on question 2 was reached.

May 2: Question 2 was discussed at the May 2 call and the WG resolved to classify it as a clarification without erratum.

Draft text available at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/0231.html

Text reviewed/approved with ammendments, at Oct. 24 telecon.

Erratum E2-36 added.

The following, from the end of 4.2.1, should be normative, not a NOTE:

NOTE: As discussed in Missing Sub-components (5.3), QNames in XML representations may fail to resolve, rendering components incomplete and unusable because of missing subcomponents. During schema construction, implementations are likely to retain QName values for such references, in case subsequent processing provides a referent. Absent target namespace names of such as-yet unresolved reference QNames in included components should also be converted if clause 3.2 is satisfied.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0240.html

Discussed at the May 2 concall: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002May/0020.html.

The WG resolved to classify R-107 as an error with erratum and to instruct HST to prepare an erratum changing 'should' to 'must' and making it a paragraph, not a note.

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

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

Erratum E1-33 added.

The XML Schema spec should specify clearly the range of numbers representable by the float type, and make explicit when numbers round to the largest finite value and when they round to infinity.

See the following for more information, and a summary of Dave Peterson's answer to the first question:

http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0245.html

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0257.html

Section 3.14.3 of Part 1 has a section called Schema Representation Constraint: Simple Type Restriction (Facets) which purports to define the interaction between the facets of a derived type and the facets of its base type. I think this section should be removed as it conflicts with the actual sections in Part 2 that define such interactions: 4.3.1.4, 4.3.2.4, 4.3.3.4, 4.3.4.4, 4.3.5.4, 4.3.6.4, 4.3.7.4, 4.3.8.4, 4.3.9.4, 4.3.10.4, 4.3.11.4, 4.3.12.4.

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

Further clarification from commentator: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002May/0023.html.

The WG resolved at the May f2f to remove non-normative from 3.14.3 and add clarifying sentence indicating that details of facet constraints are in part 2.

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

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

Erratum E1-25 added

In the Datatypes spec, section 4.3.11, there is an example for totalDigits. It indicates that the example is for numbers less than 1,000,000 with 2 fraction digits.

  <restriction base='decimal'>
    <totalDigits value='8'/>
    <fractionDigits value='2' fixed='true'/>
  </restriction>

But "fixed" means that "fractionDigits" can't be assigned another value in types derived from this type; it doesn't affect the lexical or value spaces. So 10,000,000 is allowed by the type above.

Is this an erratum?

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0282.html

Resolved at the March 22 telecon to classify R-110 as an error with erratum.

Status 04/24: Erratum text proposed: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Apr/0053.html

Discussed at the June 6 telecon. The WG decided that the example is best removed. Final revised text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jun/0037.html

Erratum E2-21 added.

Why can't foreign attributes be included on xs:appinfo and xs:documentation?

This could be useful, and seems harmless, but this is forbidden by the Schema for Schemas.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0440.html

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0455.html

Constraint "QName resolution (Schema Document)", bullet 4 states:

"4 its namespace name is either the target namespace of the schema document containing the QName or that schema document contains an <import> element information item the actual value of whose namespace [attribute] is identical to that namespace name."

Does this mean that

<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="myNS">
  <element name="e" type="string"/>
</schema>

is invalid? (Because the schema namespace is neither the target namespace, nor imported by this document.)

The spec does mention:

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

Similarly, simple type definitions for all the built-in derived datatypes (see the Derived Datatypes section of [XML Schemas: Datatypes]) are present by definition in every schema, with properties as specified in [XML Schemas: Datatypes] and as represented in XML in Schema for Schemas (normative)."

But I don't think "are present" directly leads to "can be accessed". Shouldn't bullet 4 of "QName resolution (Schema Document)" be changed to something like:

"4 one of the following must be true:

• 4.1 all of the following must be true:
  • 4.1.1 its namespace name is identical to http://www.w3.org/2001/XMLSchema .
  • 4.1.2 the kind specified is simple or complex type definition.
  • 4.1.3 its local name is identical to the name of one of the built-in types.
• 4.2 either the target namespace of the schema document containing the QName or that schema document contains an <import> element information item the actual value of whose namespace [attribute] is identical to that namespace name."

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0459.html

Discussed at the May 29, 2003 telecon. Agreed to classify as an error w/erratum. Some discussion occurred re: what new text should be added, but no consensus reached on what was required to fix the problem.

"Schema Component Constraint: All Group Limited" states:

   When a model group has {compositor} "all" all of the following must
   be true:
     1 one of the following must be true:
       1.1 It appears as the model group of a model group definition.
       1.2 It appears in a particle with {min occurs}={max occurs}=1,
           and that particle must be 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.

Consider the following named model group and complex type definitions:

<xsd:group name="allGrp">
  <xsd:all>
    <xsd:element name="a"/>
    <xsd:element name="b"/>
  </xsd:all>
</xsd:group>

<xsd:complexType name="t1">
  <xsd:sequence>
    <xsd:element name="c"/>
    <xsd:group ref="allGrp"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="t2">
  <xsd:sequence>
    <xsd:group ref="allGrp"/>
  </xsd:sequence>
</xsd:complexType>

I believe it was intended that "t1" be considered invalid, but it contains a model group which I *think* satisfies constraint 1.1 above (although it violates constraint 1.2). Is "t1" invalid? If so, are there other constraints in Structures which support this? Do we need a clarification for the "All Group Limited" constraint? Is the same true for "t2"?

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0462.html

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

The WG resolved that both examples are in error, and that the text for "All Group Limited" should be modified to make this clear. See concall minutes for possible rewording.

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

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

Erratum E1-26 added

If a schema declares a default attribute with a qualfied name (a:b="some value"), it appears that the PSVI does not fixup the [in-scope namespaces] and [namespace attributes] properties. It is therefore possible for these attributes to get out of sync.

See http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2002Jan/0090.html

The WG discussed this at the 01/25 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jan/0084.html

Related issues are:

• CR-41: Should Structures specify how / where to generate a prefix and a namespace declaration for the namespace of an attribute with a qualified name for which the schema processor must supply a default?
• The Infoset that results from schema assessment may contain Attribute Information Items that do not have a [normalized value] property and as such, the Infoset that results from schema assessment cannot generally be the subject of schema assessment itself. See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0280.html

The WG decided that these issues should be considered Future Requirements, and be reopened for 1.1

If a schema declares an attribute with a default value of type QName (a="b:c"), there is no validation of the fact that the prefix "a:" is bound in the instance document at the point where the default value is applied.

See Ashok's mail on behalf of XSL at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jan/0067.html

Discussion at the 01/25 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jan/0084.html

The type of the 'value' attribute of pattern is 'anySimpleType.' [1] Should it not be 'string'?

[1] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#element-pattern

See the first issue from: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0421.html

Proposed text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/att-0316/01-errataR-116.html

Reviewed and approved at Nov. 1 telecon.

Erratum E2-37 added.

The REC does not specify what {process contents} is for the ur-type. It should be specified as lax.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0519.html

Discussed at the May f2f. The WG discussed the possibility of making processContents "skip". Henry Thompson to work on a proposal.

Erratum is covered by that of R-54. Erratum E1-22 added.

1. The Datatypes spec states that "The value space of dateTime is the space of Combinations of date and time of day values as defined in 5.4 of [ISO 8601]." The implication of this is that 2002-02-02T12:00:00Z is a distinct value in the value space from 2002-02-02T07:00:00-05:00. But if this is so, then the canonical lexical representation (which is always in UTC with timezone designator Z) cannot represent all values in the value space.
2. The description of the value space could also be read as indicating that 12:00:00Z and 12:00:00+00:00 are distinct values, and that the year 02002 is distinct from the year 2002.

See issues 3 and 4 from: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0476.html

Ashok's response:

1. The language may not be as clear as possible but the value space represents instances of dateTime regardless of the timezone used. Thus, in your example above, where you meant to indicate two lexical representations of the same instant of time, both would map to the same value in the value space.
2. The language could be improved.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0615.html

The Datatypes spec states that the value space of date is the set of Gregorian calendar dates as defined in 5.2.1 of [ISO 8601]." It then says: "Since the lexical representation allows an optional time zone indicator...". However, there is nothing in 5.2.1 of ISO 8601 (at least not the 2000 edition) which suggests that a date can have an optional time zone indicator, or that suggests how it would be written if it were allowed. If this deviation from ISO 8601 is deliberate, which it seems to be, it should surely be flagged in Appendix D3. In fact, this seems to be the only case where Part 2 specifies a format that is definitely not allowed by ISO 8601; the other deviations are either restrictions, or things that ISO 8601 permits provided the parties agree.

See issue 6 from: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0476.html

Ashok's response:

"This is a deliberate extension to ISO 8601. Yes, it should have been included in Appendix D3."

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0615.html

The WG resolved at the May f2f to instruct the editors to draft erratum to D3 noting the variance with ISO 8601.

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

Erratum text approved at the June 6 telecon.

Erratum E2-22 added.

Why does the Datatypes spec define no canonical representation of date (unlike dateTime and time)?

See issue 7 from: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0476.html

Ashok's response:

"We should fix that. It appears to be an oversight."

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0615.html

Resolved at the May f2f to instruct the editors to draft an erratum consistent with the algorithm discussed at the meeting. See meeting minute details.

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

Reviewed/approved with ammendments, at Nov. 1 telecon.

Erratum E2-41 added.

The instance example of <analyst> in section 5.4 of the primer [1] is broken.

[1] http://www.w3.org/TR/xmlschema-0/#import

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0511.html

Resolved at the May f2f to classify this a an error, and instruct the editor to fix the example.

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

Erratum reviewed at Sept. 13 concall, but needs to be double-checked. LM agreed to check it.

Erratum E0-25 added.

Can substitution groups be restricted? If for instance I have:

 <xs:element name="head"/>
 <xs:element name="a" substitutionGroup="head"/>
 <xs:element name="b" substitutionGroup="head"/>
 <xs:element name="c" substitutionGroup="head"/>

 and:

 <xs:complexType name="base">
   <xs:sequence>
     <xs:element ref="head"/>
   <xs:sequence>
 <xs:complexType>

 is

 <xs:complexType name="derived">
   <xs:complexContent>
    <xs:restriction base="base">
     <xs:sequence>
       <xs:choice>
         <xs:element ref="a"/>
         <xs:element ref="b"/>
       <xs:choice>
     <xs:sequence>
    <xs:restriction>
   <xs:complexContent>
 <xs:complexType>

 a valid restriction?

Since substitution groups are treated as choices for particle restriction checking, the case that applies here is RecurseLax. However, the rules for RecurseLax state:

"For a choice group particle to be a valid restriction of another choice group particle all of the following must be true:

1 R's occurrence range is a valid restriction of B's occurrence range as defined by Occurrence Range OK (3.9.6);

2 There is a complete order-preserving functional mapping from the particles in the {particles} of R to the particles in the {particles} of B such that each particle in the {particles} of R is a valid restriction of the particle in the {particles} of B it maps to as defined by Particle Valid (Restriction) (3.9.6).

NOTE: Although the validation semantics of a choice group does not depend on the order of its particles, derived choice groups are required to match the order of their base in order to simplify checking that the derivation is OK."

The question should then probably be which is the order of the elements of a substitution group when they are mapped to a xs:choice?

See: http://lists.w3.org/Archives/Public/xmlschema-dev/2001Dec/0080.html

Martin Gudgin: http://lists.w3.org/Archives/Public/xmlschema-dev/2002Feb/0037.html

Henry Thompson:

Yes. The REC is underspecified in the area of the order of the implicit choice represented by a substitution group head. I think an erratum is in order, as Martin Gudgin suggested, clarifying that in this case the order constraint doesn't apply.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0512.html

Resolved at the May f2f. Editor is instructed to draft a minimalist erratum that fixes the problem.

There are situations in which the redefinition of a type, and the subsequent redefinition of the redefined type, are desirable. One such case is where a schema user would like to extend a type, not just from the original source but based on the extension of another schema user's extension (Company C extends type T from Company B, who picked it up from Company A and redefined it).

It appears that this is discouraged in the Rec. From 4.2.2:

"In all cases there must be a top-level definition item of the appropriate name and kind in the redefined schema document.

NOTE: The above is carefully worded so that multiple equivalent redefining of the same schema document will not constitute a violation of clause 2 of Schema Properties Correct (3.15.6) , but applications are allowed, indeed encouraged, to avoid redefining the same schema document in the same way more than once to forestall the necessity of establishing identity component by component (although this will have to be done for the individual redefinitions themselves)."

Some validators require that the redefined schema contain a type definition for a type that is to be redefined - that a redefinition is not sufficient. So it is not possible to redefine a redefined type. So the question is, is this something that is likely to change, or will validators vary on whether or not they support cascading redefines?

Henry's response:

Unfortunately the term 'top-level' is not formally defined in the REC. There are a number of places where things such as "all the top-level (i.e. named) components. . ." appear, so it's clear that what's meant is (XML representations of) named components which appear in one of the sets of definitions/declarations of the schema component itself. On that basis, redefs of redefs are OK, and were certainly intended to be. An erratum is in order, in my opinion.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0513.html

There are various statements in the spec of the form: "If some condition, x, is true, then, in the post-schema-validation infoset it has the properties a,b,c ..."

For example:

"If an element is valid with respect to a type definition, as per Element Locally Valid (Type), in the post-schema-validation infoset the item has a property ...

Furthermore, the item has one of the following alternative sets of properties:

[type definition]

...

"

Is it true that if condition x does *not hold*, then the processor is *not permitted* to include properties a,b,c in the PSVI, even if such information is available? I'm assuming this is what was intended, based on the clarifications drafted for the Query WG on the topic of PSVI.

If this is the case, should the Structures spec clarify this? ...perhaps with wording similiar to: "The properties a, b, c are in the PSVI if and only if ..."

As an aside, wouldn't it be useful to get at type information for an element that was not valid, if the processor had that information?

Paragraph 4.3.2, point 3, first sentence reads:

<...> and warrants that some or all of the document is conforms to that schema, <...>

and I take it the intention was:

<...> and warrants that some or all of the document conforms to that schema, <...>

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0623.html

Erratum E1-34 added

The primer should be modified to make it clear that substitution group members must be top-level elements.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0625.html

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

Erratum approved at Sept. 13 concall.

Erratum E0-24 added.

According to section 3.2.8 of "XML Schema: Datatypes" [1]:

"The order relation on time values is the Order relation on dateTime (3.2.7.3) using an arbitrary date."

Thus, if one considers the ordering of the values 00:00:00 and 24:00:00, using the arbitrary date 2002-03-06, the ordering is the same as that for 2002-03-06T00:00:00 and 2002-03-06T24:00:00. The latter value is the same as 2002-03-07T00:00:00. So, according to the definition of the order relation cited above, 00:00:00 < 24:00:00.

However, according to the definition of the canonical representation of time in section 3.2.8.2 [2]

"the canonical representation for midnight is 00:00:00"

The definition of the canonical representation would seem to imply that 00:00:00 and 24:00:00 are considered to be the same time value.

It appears that one of these 2 sections is incorrect.

[1] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#time

[2] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#time-canonical-repr

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0870.html

Resolved at the 2003-07-31 telecon to classify R-127 as a clarification with erratum, and to suggest to the editors that they add a couple of examples.

If you look at the definition of the lexical representation of decimal in 3.2.3.1 [1], it states, in part, that "if fractionDigits is specified, the number of digits following the decimal point must be less than or equal to the fractionDigits."

However, the description of the fractionDigits facet in 4.3.12 [2] doesn't mention that it constrains the lexical space in this way, i.e., by prohibiting excess trailing digits, including zeroes.

[1] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#decimal-lexical-representation

[2] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#rf-fractionDigits

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0871.html

Also see related question 1 from the following mail: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0031.html

Discussed at the May 2 concall: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002May/0020.html.

The WG decided that the facets ought to apply to the value space and instructed the editors to draft erratum.

Erratum proposed: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002May/0004.html.

Further discussion of draft erratum: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002May/0005.html.

Draft errata text reviewed at May f2f. Changes agreed upon include: striking the misleading sentences in the description of lexical form, and changing text for 4.3.11, 4.3.12 and 3.2.3.1

New errata text proposed: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002May/0051.html

Discussed at the June 6 telecon and additional changes made. Revised text based on discussion posted: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jun/0036.html

Revised text discussed at the June 14 telecon. Ammendments suggested.

Final text reviewed and approved at the July f2f. See http://www.w3.org/XML/Group/2002/07/xml-schema-ftf-minutes.html#ab3b3b3b5

Erratum E2-44 added.

It is not precisely clear from the XML Schema Datatypes specification whether leading zeros are permitted in instances of gYearMonth and gYear when (the absolute value of) the year in question is outside the range of 0001 to 9999. However, in the otherwise analogous passage of the specification of dateTime, such ambiguity is not present (such leading zeros are prohibited), and a reasonable interpretation in these other two cases is to straightforwardly follow that precedent.

See bullet (vii) from : http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/0873.html

Discussed at 2003-11-20 telecon. Resolved to classify as clarfication w/erratum - DaveP to draft text.

The type of the id attribute on the schema element is too constraining - the schema for schemas is invalid.

See : http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/1010.html

Resolved at the May f2f to classify as an error and instruct the editor to change the version attribute.

Erratum added to doc as E1-9

Since RFC 1766 is now obsoleted by RFC 3066, we would like to submit that the XMLSchema spec. needs to

1. Correct its language to parallel that of XML 1.0 (in the latter's reference to RFC 1766 "or its successor on the IETF Standards Track") thus dragging in RFC 3066.
2. Correct its language pattern according to the syntax defined therein, namely value="([a-zA-Z]{1,8})(-[a-zA-Z0-9]{1,8})*"

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/1069.html

and http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/1092.html

The WG resolved this at the May f2f, deciding to instruct the editors to draft erratum that substitutes 3066 for 1766, formulate an appropriate pattern and references the pattern instead of XML 1.0 2nd edition.

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

Text approved at June 14 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jul/0009.html

Erratum E2-25 added.

In XML Schema Part 2: Datatypes W3C Recommendation 02 May 2001 change:

(2000-03-30 + P1D) + P1M = 2000-03-31 + P1M = 2001-04-30

to:

(2000-03-30 + P1D) + P1M = 2000-03-31 + P1M = 2000-04-30

(2001 should be 2000)

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/1099.html

Errata text proposed: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Apr/0052.html

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

Erratum E2-20 added.

We fail to say how equiv comparisons are performed on anyURI (e.g., for checking a literal against an enumeration). I'd also note that we don't say anything of this kind about a lot of types (string, etc.). We rely on phrases like "if the {value} is in the value space...".

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JanMar/1100.html

Resolved at the 2003-07-11 telecon to classify R-132 as an error.

The regular expressions given for matching XPath strings are incorrect in the Schema for Schemas.

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

Resolvled at the July 2003 f2f to classify as an error w/ erratum.

Appendix F says:

"All XML characters are valid character ranges, except as follows:...

The ^ character is only valid at the beginning of a positive character group if it is part of a negative character group; ...".

However, the EBNF doesn't seem consistent with this. Consider

[^X]

This is ambiguous wrt the EBNF, since "^" is an XmlCharIncDash and thus a charRange: according to the EBNF it could be a powCharGroup containing "^" and "X" or a negCharGroup containing "X". Consider also

[^]

According to the EBNF, this is unambiguously a posCharGroup containing "^", but this is inconsistent with the prose.

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

Note: R-134 was reopened at the Feb. 21 2003 telecon.

F.1.1 rightly disallows \p{Cs} on the basis that surrogate characters "do not occur at the level of the "character abstraction" that XML instance documents operate on." On the same basis, shouldn't IsHighSurrogates, IsHighPrivateUseSurrogates and IsLowSurrogates also be disallowed within \p{} and \P{}?

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

Resolved at the May f2f to classify this as an error, instructing the editors to draft erratum reflecting changes suggested by commentator.

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

Reviewed and approved, with ammendments, at Oct. 24 telecon.

Erratum E2-38 added.

Is the following invalid?

<xsd:element name="root">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="Book" maxOccurs="unbounded">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="isbn" type="xsd:string"/>
          <xsd:sequence>
          <xsd:attribute name="name" type="xsd:string" use="required"/>
        <xsd:complexType>
        
        <xsd:key name="BookKey">
          <xsd:selector xpath="."/>
          <xsd:field xpath="isbn"/>
        <xsd:key>
        
      <xsd:element>
    <xsd:sequence>
  <xsd:complexType>
<xsd:element>

The point to note here is that the selector XPath contains the expr '.'

The XMLSchema Rec says:

[[ {selector} specifies a restricted XPath ([XPath]) expression relative to instances of the element being declared. This must identify a node set of subordinate elements (i.e. contained within the declared element) to which the constraint applies.

]]

Further, 3.11.4 The Identity-constraint Definition Validation Rules, states:

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

1 The {selector}, with the element information item as the context node, evaluates to a node-set (as defined in [XPath]). [Definition:] Call this the target node set.

2 Each node in the target node set is an element node among the descendants of the context node.

3 ....

]]

Looking at point 2 above, it reflects that, '.' cannot be used as the XPath expr for a selector. Does *descendants of the context node* include the context node?

On the other hand the production rule for the XPath expr for the selector allows '.' as a valid XPath expr.

A clarification is requested.

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

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

Discussed at the May 23 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002May/0091.html

Resolved to classify R-136 as an error and instruct editor to draft erratum.

Proposed text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/att-0225/01-R-161etc.html

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

Erratum E1-35 added.

Can subsitution groups contain local elements?

Henry Thompson:

The Schema for Schemas rules this out. But, this only applies to the XML representation layer.

It's a bug that there's no clause in "Schema Component Constraint: Element Declaration Properties Correct" ruling this out for components as well.

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

Discussed at the May 23 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002May/0091.html

Resolved to classify R-137 as an error and instruct editor to draft erratum ading a suitable component constraint.

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-36 added.

1. Structures specifies that the simple ur-type defintion must not be used as a base type definition for any user-defined simple types. But, the schema for schemas includes type derivations for the built-in primitive types with base types of anySimpleType.
2. XMLSchema.xsd includes a trailing space in the version.

See bullets 1 and 4 in the following email. Henry Thompson's remarks are included: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0033.html

In addition, Jeni Tennison asks where there is a normative constraint for this rule about anySimpleType: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0034.html

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

A related mail on "renaming" anySimpleType and "anyType": http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0052.html

Discussed at the May 23 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002May/0091.html

Henry Thompson to draft erratum:

• Clarifying that the schema for schemas can derive primitives from anySimpleType, although users cannot.
• Making the constraint normative, as per Jeni Tennison's point.

Erratum incorporated within that of R-54.

ISO 8601 section 5.3.2 allows 24:00:00 as a representation of midnight. Appendix D of XML Schema Part 2 says that the hh field runs between 0 and 23, but there is no mention of 24:00:00's not being allowed as a difference between XML Schema and ISO 8601.

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

Discussed at the May 23 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002May/0091.html

Editors to draft erratum correcting appendix D, and making 24:00 a legal form.

Proposed text may be found at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Sep/0120.html

Text http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Sep/att-0228/01-ErrataR-139.html approved at Oct. 4 telecon.

Erratum E2-45 added.

Consider the dateTime of the last leap second:

1998-12-31T23:59:60Z (P)

This instant in time can also have the lexical representation of, for example,

1998-12-31T22:59:60-01:00 (Q)

Section 3.2.7.3 defines the algoritm for comparing two dateTimes as follows:

"A.Normalize P and Q. That is, if there is a timezone present, but it is not Z, convert it to Z using the addition operation defined in Adding durations to dateTimes (E)"

Now in our example P has a Z timezone, but Q doesn't, so we need to normalize Q to Z using Appendix E. But E.1 says:

"Leap seconds are handled by the computation by treating them as overflows. Essentially, a value of 60 seconds in S is treated as if it were a duration of 60 seconds added to S (with a zero seconds field). All calculations thereafter use 60 seconds per minute."

This implies that Q is first mapped into:

1998-12-31T23:00:00-01:00

Then following the rest of algorithm in Appendix E, this will map into:

1999-01-01T00:00:00Z

Now comparing:

1998-12-31T23:59:60Z

and

1999-01-01T00:00:00Z

we find that

P < Q

But P and Q represent the same value. So we have a contradiction: two lexical representations represent the same value, but the value represented by one lexical representation is less than the value represented by the other lexical representation.

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

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

Discussed at the May 2003 f2f. Decided to classify as error w/erratum and come back later for detailed consideration.

In section 3.2.7.3 on the order relation of dateTime, at B.1, it says:

1.. If P[i] and Q[i] are both not specified, continue to the next i 2.. If P[i] is not specified and Q[i] is, or vice versa, stop and return P <> Q

This doesn't make any sense to me. When could P[i] or Q[i] be "not specified"? In dateTime all fields are specified.

When things like gYearMonth appeal to the dateTime order, they do so by saying eg "the order relation on gYearMonth values is the order relation on their starting instants", so in this case also all fields are totally specified.

I think the above two sentences should be deleted.

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

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

Discussed at the May 2003 f2f. Decided to classify as error w/erratum and come back later for detailed consideration.

The order relation on date is specified as:

"If date values are considered as periods of time, the order relation on date values is the order relation on their starting instants."

This makes sense to me.

The order relation on time is specified as:

"The order relation on time values is the Order relation on dateTime (3.2.7.3) using an arbitrary date."

This also makes sense to me.

Now consider the order relation on eg gMonthDay:

"If gMonthDay values are considered as periods of time, the order relation on gMonthDay values is the order relation on their starting instants."

I don't think this is quite right. A gMonthDay is not a single period of time but a recurring period. The dateTime ordering relation compares two specific instants of time. Thus in order to turn a gMonthDay into a specific instant of time, you need to use an arbitrary year (just as with time you need to use an arbitrary date). However, I'm guessing --02-29 is allowed as a gMonthDay; if so, the year is not an arbitrary year but an arbitrary leap year.

So the spec should say something like:

"If gMonthDay values are considered as periods of time using an arbitrary leap year, ..."

Similarly, for gMonth and gDay.

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

Discussed at May 31 telcon. Resolved to classify as error w/erratum.

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

Text approved at June 14 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jul/0009.html

Erratum E2-26 added.

Derivation by restriction does not copy attribute wildcards from the base to the derived type def.

Accordingly, the following type definitions have lost the

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

they were meant to have:

  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

I propose an erratum to add the above wildcard to all of these.

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

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

Resolved at the May 31 telecon to classify R-143 as an error with erratum, and instruct the editor (HST) to draft an erratum along the lines suggested.

Erratum added: E1-8.

Section E.1 contains the sentence:

"If a field in S is not specified, it is treated in the calculation as if it were the minimum allowed value in that field, however, after the calculation is concluded, the corresponding field in E is removed (set to unspecified)."

I think this sentence is in error and should be deleted.

The ordering relation for eg gYear specifies: "the order relation on gYear values is the order relation on their starting instants". In this case as in others, we only need to compare fully-specified dateTime instants.

The value space of gYear must be considered as containing both the year number and the time zone (if any). To compare two values in the gYear value space, you convert them to values in the dateTime value space (by using their starting instants). Then you compare those two dateTime values using the algorithm in 3.2.7.3.

That sentence in section E.1 only makes sense if you take the view that the value space of the partially specified dateTimes (like gYear, gMonth) does *not* include time zones; in this case, you would need to normalize out the time-zone before converting to a time-instant for comparison, and so would be applying addition to a partially-specified date time. But this leads to nonsense results, as Kawaguchi-san pointed out:

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

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

Resolved at the July 2003 f2f to classify as an error w/erratum.

Appendix D says:

"A value of 60 or more is allowed only in the case of leap seconds.

Strictly speaking, a value of 60 or more is not sensible unless the month and day could represent March 31, June 30, September 30, or December 31 in UTC. Because the leap second is added or subtracted as the last second of the day in UTC time, the long (or short) minute could occur at other times in local time. In cases where the leap second is used with an inappropriate month and day it, and any fractional seconds, should considered as added or subtracted from the following minute."

Consider a dateTime like this:

1970-01-01T09:30:60Z

This is completely bogus for a number of reasons (leap seconds only on last day of March, June, September; leap second only on last second of day; no leap second before 1972). The last sentence above would seem to suggest that this should be silently accepted and converted to 1970-01-01T09-31-01Z. This surely cannot be right. That date is as bogus as a date that specifies the 29th day of February in a year that is not a leap year. It is very easy to imagine an off-by-1 software bug that generates 60 instead of 59 in the second field. It cannot be right for a validator to accept and mangle it into a different (but valid) date.

I think we can distinguish the following questions:

1. Assuming that an XML Schema processor encounters a leap second and classifies it as (a) definitely valid (b) unsure or (c) definitely invalid, what should it do in each case? I would argue in case (c) it should give an error and in case (a) or (b) it should allow it.
2. What algorithm is the XML Schema processor supposed to use for classifying a leap second as (a), (b) or (c)? Each of the following is a piece of knowledge that an XML Schema processor could apply:

   (a) No leap seconds occurred before 1971-12-31

   (b) All leap seconds that have occurred so far have occurred on 31st December or 30th June.

   (c) Leap seconds only occur on 31st March, 30th June, 30th September, or 31st December (in GMT)

   (d) Leap seconds only occur on the last second of the day.

   (e) The leap seconds that occurred so far are: 1971-12-31,...,1998-12-31

   (f) There will be no leap second on 2002-06-30.

   (g) The next potential leap second is 2002-12-31 (or maybe 2002-09-30).

   Which of the above is an XML Schema processor expected to apply in validating a leap second?

3. How should future leap seconds be handled? For example, what if a processor running today encounters the date 2010-12-31T23:59:60Z? Now it's possible that at some future point this will be declared to be a leap second. But at the moment, we know for certain that it has not been decided whether it should be a leap second. Given this, should a user get an error if today they feed 2010-12-31T23:59:60Z to an XML Schema processor?
4. How should leap seconds in a time value with a time zone be handled? I guess it should be rejected if it does not correspond to 23:59:60Z. But what recurring instant of time would this denote? Every leap second?
5. How should leap seconds in a time value without a time zone be handled? Because of time zones, I guess anything is OK.
6. How should leap seconds in a dateTime value without a time zone be handled? By analogy with 3.2.7.3, one approach might be to say that a dateTime P without a time zone is valid if and only if there is a time zone T where -14:00 <= T >= 14:00 such that PT is valid.

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

Resolved to classify as error w/erratum. At the 2003-09-04 telecon, DaveP made a proposal for how to address the issues, which was accepted. Editors to draft erratum accordingly.

Section D.1 says "A value of 60 or more is allowed only in the case of leap seconds". Is the "or more" just intended to cover a fractional second or is it intended to allow values >= 61? The specs for Java and ISO C allow a value of 61, but as far as I can see the official spec for UTC only allows a single leap second.

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

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

3.2.6.1 says "The values of the Year, Month, Day, Hour and Minutes components are not restricted but allow an arbitrary integer. Similarly, the value of the Seconds component allows an arbitrary decimal."

What exactly is the lexical form of arbitrary integer and arbitrary decimal? Does it mean the lexical form of the "decimal" and "integer" datatypes as defined in section 3.2.3 and 3.3.13? Apparently not since it says "P-1347M" is not allowed even though "-1347" is a perfectly good integer. If not, what does it mean?

Specifically, which of the following are allowed?

(a) P+1Y
(b) P-1Y
(c) P-0Y
(d) P.1S
(e) P1.S

ISO 8601 allows only a sequence of digits, but since ISO 8601 is not cited normatively a reader cannot rely on that. The provision of fractional sections goes beyond what ISO 8601:1988 allows. However, according to my (draft and thus perhaps no longer correct) copy, ISO 8601:2000 does not allow any of (d) or (e) (even though they are valid instances of the XML Schema decimal data type).

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

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

Discussed at the May 31 telecon. The WG resolved to to classify R-147 as an error with erratum, and instruct the editors to draft an erratum along the lines specified.

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

Text approved at June 14 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jul/0009.html

Erratum E2-23 added.

Is a trailing decimal point allowed in the seconds field of dateTime and time? For example, is "12:45:00." allowed? 3.2.7.1 says "any number of digits after the decimal point is supported", but I believe ISO 8601:2000 requires that any fractional part have at least one digit.

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

Discussed at the July 2003 f2f. WG decided that the 2E text already takes care of this problem. Asir to write to James to confirm.

Is +0 allowed as a nonPositiveInteger? At the moment there's a contradiction. 3.3.14.1 says "nonPositiveInteger has a lexical representation consisting of a negative sign ("-") followed by a finite-length sequence of decimal digits (#x30-#x39). If the sequence of digits consists of all zeros then the sign is optional." This doesn't allow +0. On the other hand 0 is in the value space of nonPositiveInteger and +0 is a legal representation of ) in the lexical space of integer.

Either

(a) the prose in 3.3.14.1 needs fixing, or

(b) the schema for schema needs to add a pattern facet to the definition of nonPositiveInteger that excludes +0

If you do (b), then you will probably want to fix nonNegativeInteger to disallow "-0". However, at the moment there's no contradiction since the prose for nonNegativeInteger allows "an optional sign" not just an optional positive sign.

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

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

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

Discussed at the May 31 telecon. WG resolved to to classify R-149 as a clarification with erratum, and instruct the editors to draft an erratum fixing the prose.

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

Final approved text may be found at: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0086.html

Erratum E2-27 added.

For decimal types, it's explicitly mentioned in the spec that the decimal digits have to be in the range #x30-#x39. But for date/time types, the Rec only refers to ISO 8601. Are digits outside of the range #x30-#x39 allowed?

See item 2 from: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0031.html

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

Errata text approved with ammendments at the June 28 telecon. See minutes for details: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jul/0004.html

Final modified text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jul/0003.html

Erratum E2-28 added.

Questions include:

1. Is it defined on "value spaces", or "types"?

   In 4.2.1 of the datatype spec: "Every value space supports the notion of equality, ...". So it seems that "equal" is defined on "value spaces". Does this imply that two (unconnected) types (with the same value space) can have equal values? For example, hexBinary and base64Binary have the same value space ("the set of finite-length sequences of binary octets"). hexBinary value "00" and base64Binary value "AA==" both represent one byte of value "0". Then are the two values equal?

   But 3.11.1 of the Structures spec says "Values of differing type can only be equal if one type is derived from the other, and the value is in the value space of both". Here it seems to indicate something different. Is this a contradiction?

2. Do the types have to be related by restriction or union?

   If type A restricts "integer" by setting "minInclusive=0", and B restricts "integer" by setting "maxInclusive=10". Now A and B are not related by restriction or union. But I still expect value "5" from both types (values spaces) to be equal.

   (If they have to be related by restriction or union, doesn't 3.11.1 of the structure spec need to be modified to be more strict, instead of simply saying "derived from"?)

The commentator's views on these issues:

1. "equal" should be defined on value spaces, because equal values are equal, no matter how they were lexically represented.
2. Types used to generate equal (actual) values don't need to be related. As long as there exist a (primitive) value space to which both values belong, and the two values are equal in that value space, then they are equal. This means hexBinary and base64Binary can generate equal values, so can QName and NOTATION. Further on this, maybe the value space of "float" should (or already is) be a subset of that of "double", so that these types can generate equal values.

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

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

Discussed at the May 31 telecon. The WG divided the question into:

• R-151a: can types derived from the same primitive type, but not derived from each other, can have equal values?
• R-151b(i): should we make an explicit statement that the primitive value spaces are disjoint?
• R-151b(ii): should we add a note to the descriptions of base64Binary and hexBinary saying explicitly that their value spaces are disjoint?

RESOLVED unanimously: to classify R-151a (on whether types derived from the same primitive type, but not derived from each other, can have equal values) as a clarification with erratum, and instruct the editors to draft an erratum saying yes they can.

RESOLVED: to classify R-151b(i) as a clarification with erratum and instruct the editors to draft an erratum saying explicitly that the primitive value spaces are disjoint.

On R-151b(ii) we considered a proposal to class it a clarification with erratum and to instruct the editors to draft an appropriate clarification. The proposal failed.

Proposed text may be found at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jun/0061.html

Brief discussion of the text began at the June 20 telecon, but no detailed review of the text was done.

Final revised text http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Sep/0057.html approved at Sept. 13 concall.

Erratum E2-46 added.

3.2.6.1 says:

"The designator 'T' shall be absent if all of the time items are absent"

Shouldn't this be "if and only if" rather than "if"? I don't think something like P24H can be allowed since there would be an ambiguity whether M meant months or minutes. (The use of "shall" here feels rather ISO-ish; tt would be more stylistically consistent to use "must".)

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

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

Discussed at the May 31 telecon. Errata text proposed at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002May/0151.html was approved.

Erratum E2-24 was added.

Is the public attribute of notation optional or required? The Schema for Schemas and the XML representation of Notation Declaration schema components indicates it is required. However, section 3.12.1 states that it is optional.

See the following for more info, links to the spec, etc.: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0097.html

Discussed at Sept. 13 telecon. The WG agreed that the S4S is likely in error, but HT to verify w/ Richard Tobin, and then draft erratum.

Final text available at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/att-0312/01-R-161etc.html

Text reviewed and approved at Nov 1 telecon.

Erratum E1-16 added

In the final part of line 6 of paragraph 1 of Chapter 5.1 the text "with an other information" should, I think, read "with any other information".

See the following for more info: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0107.html

Resolved at the July 2003 f2f to classify as editorial.

Found a few typos in the Primer that I don't think have been reported yet:

1. In the paragraph just before section 2.5, "it has an anonymous simple type derived from integer..." This should be positiveInteger, not integer.
2. Table 2 - note (5) at the bottom - "calender" should be "calendar".
3. Section 4.2, first paragraph "...technique we used in in Section 2.5.1..." The word "in" is repeated.
4. Table D1 - "Espanñola" should say "Española" (with no "n").

See the following for more info: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0118.html

Errata E0-3,4,5,6 added.

Consider:

<complexType name="something" mixed="true">
	<simpleContent>
		<restriction base="string">
		</restriction>
	</simpleContent>
</complexType>

This is a unique combination, a complex type with simple content and mixed content type. I believe that this combination is valid per XML Schema 1.0 REC.

Personally, I believe that this combination is invalid and hope this will be ruled out explicitly.

See the following for more info: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0127.html

Response from Henry: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0141.html

The WG discussed this issue at the Sept. 13 telecon, and agreed to add a "warning" about this now (2nd edition), with the intent that constraints will be added to 1.1. HT to draft erratum.

Proposed text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/att-0225/01-R-161etc.html

Reviewed/approved at the Oct. 25 telecon.

Despite the fact that multiple non-normative portions of the spec make it clear that ambiguous content-models were not intended to be allowed, the language used in the normative parts of xml-schema (structures) allows for ambiguous/non-deterministic content-models.

The 'Unique Particle Attribution' constraint combined with section 3.8.4 _would_ require non-ambiguous content-models, were it not for the interaction of minOccurs/maxOccurs with these rules.

There are 2 relatively simple fixes that I can think of:

1. make it clear that minOccurs/maxOccurs are just syntactic sugar, and that the 'Unique Particle Attribution' constraint should not be impacted by this sugar.
2. change section 3.8.4 to indicate that the partitioning of the content must be possible based only on the current position in the content-model and the name of the next element. (I.e. make it explicit that ambiguity is not allowed.)

Here is an example:

--- t.xsd
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" >
  <xs:element name="root">
    <xs:complexType>
      <xs:sequence minOccurs="2" maxOccurs="2">
        <xs:element name="a" minOccurs="2" maxOccurs = "unbounded"/>
        <xs:element name="b" minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

---- t.xml
<?xml version="1.0"?>
<root><a/><a/><a/><a/><root>


---- t2.xml
<?xml version="1.0"?>
<root><a/><a/><a/><b/><a/><root>

Both t.xml and t2.xml are valid according to the content-model, and in both cases there is unique particle attribution, but upon having parsed the 2nd and encountering the 3rd , it is impossible to know whether to start a new sub-sequence or to continue the current. For 1.xml, it is necessary to start a new sub-sequence at that point, and for t2.xml it is necessary to hold off.

See the following for more info: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0129.html

Response from Henry: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0139.html

Discussed at the Sept. 20 concall.

RESOLVED: to classify R-157 as clarification without erratum.

This is a fragment from the Schema for Schemas

<xs:complexType name="topLevelAttribute">
  <xs:complexContent>
   <xs:restriction base="xs:attribute">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:element name="simpleType" minOccurs="0" type="xs:localSimpleType"/>
    </xs:sequence>
    <xs:attribute name="ref" use="prohibited"/>
    <xs:attribute name="form" use="prohibited"/>
    <xs:attribute name="use" use="prohibited"/>
    <xs:attribute name="name" use="required" type="xs:NCName"/>
   </xs:restriction>
  </xs:complexContent>
</xs:complexType>

attribute 'use' is ruled out,

<xs:attribute name="use" use="prohibited"/>

However, the prose in section 3.2.3 (constraints on XML Representation) doesn't say anything about the 'use' attribute.

I believe that the schema for schemas is correct and hope, the prose will rule this out explicitly.

See the following for more info: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0128.html

Response from Henry: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0138.html

Resolved at the July 2003 f2f to defer to 1.1, adding it as a requirement.

The REC distinguishes between attribute decls and attribute uses in order to allow refs to global decls to have their own defaulted and/or fixed values. We correctly fall back from the use to the decl in checking fixed values, but we don't actually specify the fallback in building the default. This actually requires a one-word fix (insert 'effective' before {value constraint} in Schema Information Set Contribution: Attribute Default Value in section 3.4.5) with a link to the definition of effective value constraint.

This is a 'must fix', in my view.

See the following for more info: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0137.html

Discussed at the Sept. 13 telecon. The WG agreed with HT on the proposal and is instructed to draft erratum text.

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

Erratm E1-38 added.

I am unable to determine the intent and meaning of section 3.14.6 Constraints on Simple Type Definition Schema Components.

My recall is that the intent of instance type overides is ONLY to apply stricter constraints on the data to be validated. Yet, when working an example, the use in extensibility deriving alternative types became apparent.

Read one way:

• unitedColor is validly derived by union from rgbColor and the instance is valid. If So, the text in parenthesis is not normative and confusing.

Or another way

• unitedColor is NOT validly derived from rgbColor because it is not derived by restriction and therefore the instance is not valid. If so, why is union in the list?

Analysis:

My guess: the first two test-colors are valid, the last three are not. xsi:type can be a built-in type or a globally defined type in the schema but must be a type that is derived from the original type of the element or attribute.

I think the ruling clause is:

2.2.4 does not apply because B (rgbColor) is not an union.

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.

where in this case, B (rgbColor) is restriction of unsignedByte

when D = unitedColor - The fact that a union exists should have no impact, the union is in D's variety and the text in the first para says "of which only restriction is actually relevant"

Yet, the only reason to believe that it is not validly derived is the clause 2.2.2. This logic becomes circular.

See the following for more info and examples: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0152.html

Discussed at the Sept. 19 conference call.

RESOLVED: to class R-160 as clarification without erratum (i.e. no change is required). PVB to draft reply to commentator on R-160.

The description of QName resolution in Part 1, section 3.15.3, specifically item 4 doesn't seem to handle the case of referring to a component with no target namespace (where xs:import has no namespace attribute).

See the following for more info: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0162.html

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

Discussed at the Sept. 13 telecon. The WG agreed the commentator has pointed out a bug, and HT is directed to draft an erratum fixing the problem.

Proposed text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/att-0312/01-R-161etc.html

Discussed at the Nov. 1 telecon.

Erratum E1-39 added.

In the Structures spec, under Section 3.14.6 -> Schema Component Constraint: Derivation Valid (Restriction, Simple)

• 2.2 is missing the whitespace facet.
• 3.1 should be removed since other unions are allowed.

See the first paragraph of the following for more info: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0135.html

Discussed at the Sept. 19 concall.

Resolved to classify R-162 item 2.2 as error with erratum, and 3.1 as clarification without erratum.

Erratum E1-22 added

The Schema for Schemas and the Rec should be consistent wrt where annotations are allowed. The Schema for Schemas permits an annotation on any element/attribute element, but the Rec is missing annotation information for some schema component definitions.

See the following: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0170.html

as well as an earlier posting with an example: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0020.html

Resolved at the July 2000 f2f to:

1. add a clarification to the errata doc indicating that annotations get lost in this situation
2. integrate this case of lost annotations into RQ-130

The commentator suggests that the type of zip code in the purchase order schema be changed from decimal.

See the following: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0172.html

Resolved at the 2003-07-31 telecon to defer to 1.1, and to suggest to the editor that she use postal codes to illustrate patterns.

Appendix H of Part 1 includes the sentence:

"Determinize this automaton, treating wildcard transitions as opaque."

What is the meaning of "treating wildcard transitions as opaque"?

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

Henry's response: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0000.html

Resolved at the 2003-09-11 concall to classify R-165 as a clarification with erratum, and to instruct the editors to produce requisite prose.

If an element matches <any> with processContents=skip, but has an xsi:type attribute, may/must it be assessed?

Schema-Validity Assessment (Element) disallows finding an element declaration or laxly validating using the ur-type when the context-determined declaration is skip, but does not mention skip in section 1.2 which includes the xsi:type case.

It seems most reasonable to me that an element matching skip should be completely untouched by the validator, just like an element outside the validation-root.

See the following: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0002.html

Ashok's response: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0004.html

2003-09-11: This is a duplicate of issue R-193 and is being closed.

Assessment Outcome (Attribute) only applies to attributes that have been assessed. Since there is no difference between assessment and strict assessment for an attribute, an attribute that has not been strictly assessed will never have a [validation attempted] property, so it is impossible for the [validation attempted] property to be none. Similarly the [validity] property can never be notKnown.

This seems odd. An attribute with no type declaration cannot be assessed (Schema-Validity Assessment (Attribute)), so it will never have any PSVI properties, whereas it would be natural for it to have [validation attempted] = none and [validity] = notKnown.

See the following: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0003.html

Discussed at the Sept. 20 concall.

RESOLVED: to classify R-167 as clarification without erratum, and to bring the issue up again in the context of 1.1.

[schema error code] is only set when an element or attribute's local validity has been assessed (Validation Failure (Element) or (Attribute)).

So no error code is set when no declaration or type can be found for an element or attribute, because in this case local validity is not assessed. But it seems to me that this should produce some error code if the context-determined declaration is mustFind.

See the following: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0005.html

Should the WG reconsider whether the public identifer of schema notations should be a string instead of anyURI?

See the following: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0007.html

See also related Rec Issue R-32.

Sept. 27: RESOLVED: to classify R-169 as an error with erratum, and to instruct the editor to correct the XML Representation display and the schema for schemas, and to make a private utility type to model XML 1.0 2e as closely as possible.

Erratum covered by that of R-153.

XML Schema Part 1 (Structure) and XML Schema Part 2 (Datatypes) seem to have different notions of "derived" for simple types.

According to Part1, setion 3.14.6, Schema Component Constraint: Type Derivation OK (Simple), type unions and list extensions are NOT "derived" from their respective member types (but their member types are regarded as "derived" from the union type resp. list extension).

This is in contrast to Part 2, which defines union types and list extensions as "derived" from their respective member types (2.5.2.2 and 2.4.2.3).

The inconsistent semantics of "derived" can lead to confusion among schema authors, in particular when working with substituion groups, instance type overriding, and redefinitions.

We suggest to drop the term "derived" for type unions and list extensions in XML Schema Part 2 and to replace it with the term "constructed". This would also affect the classification of the built-in types NMTOKENS, IDREFS, and ENTITIES, which are no longer "derived by list" but "constructed by list".

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

Ashok's response: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0022.html

Discussed at the Sept. 27 concall. RESOLVED: to defer R-170 to 1.1.

In Element Locally Valid (Element) 5.2.2.2.2, the actual value of a simply-typed element must match the canonical lexical representation of the value of the fixed value constraint.

In the analogous case for attributes, Attribute Locally Valid 4, the actual value must match the value of the fixed value constraint (no mention of canonical lexical representation).

Apart from the inconsistency, it doesn't make sense for an actual value to match a representation rather than a value.

Presumably it is intended that the match is a value match in both cases.

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

Discussed at the Sept. 27 concall. RESOLVED unanimously: to classify R-171 as error with erratum.

Consider the schema:

      <xsd:schema
        xmlns="http://schematests.com"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        targetNamespace="http://tests.com">

        <xsd:element name="root">
            <xsd:complexType>
                <xsd:sequence>
                    <xsd:element name="name" maxOccurs="unbounded"/>
                </xsd:sequence>
            </xsd:complexType>
            <xsd:key name="nameKey">
                <xsd:selector xpath="./name"/>
                <xsd:field xpath="."/>
            </xsd:key>

        </xsd:element>

      </xsd:schema>

Since no type is declared for the local "name" element, by the properties tableaus in [1], it must have the ur-type.

Consider the instance document

      <my:root
        xmlns:my="http://tests.com"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://tests.com idAnytype.xsd">
        <name>Jack Daniels<name>

        <name>Johnny Walker<name>

        <name>Sam Adams<name>
      <my:root>

From the 3rd point of [2]:

"3 For each node in the target node set all of the {fields}, with that node as the context node, evaluate to either an empty node-set or a node-set with exactly one member, which must have a simple type. "

[3] tells us that the ur-type can behave as a simpleType "according to context":

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

This raises two questions:

1. Is it valid for a <field> to match an element with the ur-type definition under any circumstances?
2. If such a match may sometimes be valid (presumably when the element only contains textual content):
   1. If the element contains text, in which value space should the schema-normalized value of the field be considered to lie? This will be significant in the case of keyref matches, especially in light of the recent discussions concerning the incomparability of values from disjoint value spaces.
   2. I presume that an error should be raised if the instance of the ur-typed element actually contains element content? Or should the <field> match simply fail?

[1]: http://www.w3.org/TR/xmlschema-1/#declare-element

[2]: http://www.w3.org/TR/xmlschema-1/#section-Identity-constraint-Definition-Validation-Rules

[3]: http://www.w3.org/TR/xmlschema-1/#key-urType

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

Henry's response: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0089.html

Discussed at the 2003-10-17 telecon. RESOLVED: (a) to class R-172 as clarification with erratum, and instruct the editor to draft an erratum which restricts fields to matching types which have LV mappings (informally, 'concrete' simple types), and (b) make a note to come back to this in 1.1, after solving RQ-024 and RQ-141 (the issue about abstract simple types).

What is the canonical lexical representation of duration?, and how do I get there from any other lexical representation.

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

Discussed at the Sept. 27 concall. RESOLVED: to classify R-173 as clarification without erratum, AM to write a response to the commentator.

The definition for {namespace schema information information items} [1] includes 3 properties - {schema namespace}, {schema components}, {schema documents}. The XML Schema Recommendation specifies that the {schema components} property could be empty:

[[ The {schema components} property is provided for processors which wish to provide a single access point to the components of the schema which was used during assessment. Lightweight processors are free to leave it empty.. ]]

On the other hand, the specification seems to require that the {documents} property should be exposed by all (including lightweight) processors. Since exposing schema documents is as expensive as exposing schema components, this requirement seems unreasonable, and thus looks like a bug in the spec.

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

See:

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

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

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

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

Discussed without resolution at the 2003-10-17 telecon.

Discussed/resolved at the 2003-10-23 telecon.

RESOLVED: class R-174 as issue for 1.1.

ACTION: MSM to write Elena Litani explaining our decision on this candidate erratum and noting that since every property in the infoset is optional, the provision of a document information item can be approximately as lightweight as the implementor cares to make it. (In particular, it can be just the [base URI] property, or in the extreme case an 'information item' with no properties at all.)

The value space of normalizedString allows all characters except xD, xA, and x9. The lexical space allows all characters except xD and x9. What is the mapping from the lexical space to the value space: what happens to an xA character in the lexical space (is it removed? replaced by an x20?). The canonical lexical representation, presumably, is the same as the string in the value space: I think we should be told.

Presumably the lexical space represents the value after the XML parser has done its normalization. So in practice, a tab character is allowed in an attribute of type normalizedString (because the XML parser will turn it to a space), but a tab character is not allowed in an element of type normalizedString (because the XML parser will leave it unchanged). Is this interpretation correct?

I find it hard to understand why the lexical space doesn't allow any string, with a mapping to the value space achieved by normalizing whitespace characters. Alternatively, the lexical space should be identical to the value space. The current definition seems nonsensical.

See question 1 from the following: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0026.html

Henry's response: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0036.html

Discussed at the Sept. 27 concall. Resolution: The lexical and value spaces should be described in the same way (the more restrictive way). AM: fix 3.3.1.

RESOLVED: to classify R-175 as error with erratum and to align the correction with R-83, E2-17.

Proposed text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/att-0002/01-ErrataR-175.html was approved at the Oct. 4 telecon.

Consider the following schema fragment:

   <xs:complexType name="mixed" mixed="true">
     <xs:choice minOccurs="0" maxOccurs="unbounded">
       <xs:element ref="test:a"/>
       <xs:element ref="test:b"/>
     <xs:choice>
   <xs:complexType>
 
   <xs:element name="root">
     <xs:complexType>
       <xs:complexContent>
         <xs:extension base="test:mixed">
           <xs:attribute name="id" type="xs:ID"/>
         <xs:extension>
       <xs:complexContent>
     <xs:complexType>
   <xs:element>

Is the following instance valid? (i.e. is root allowed to have mixed content?)

 <root xmlns="http://example.com/test">
   ccc<a>aaa<b>bbb<b>aaa<a>ccc<b>bbb<a>aaa<a>bbb<b>ccc
 <root>

Henry's response: Yes. Note, however, that this "redundancy" can only be avoided when the extending definition is empty -- if any substantive element content is added, then the result is specified by the REC to take its 'mixed' from the extending definition. But the REC also rules out extending mixed with element-only or vice-versa, so there's no point.

This isn't a big deal, but it should probably be fixed, by

1. specifiying that in complexContent extension, the mixed _always_ comes from the base;
2. ruling out conflicting 'mixed' on <complexType> or <complexContent> when deriving by extension.

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

Discussed at the 2003-11-14 telecon. Sandy Gao to study the relevant sections and report back to the WG

Sandy's research: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Dec/0029.html

Question:

From http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-TokenizedType

Validity constraint: ID

Values of type ID must match the Name http://www.w3.org/TR/2000/WD-xml-2e-20000814 production. A name must not appear more than once in an XML document as a value of this type; i.e., ID values must uniquely identify the elements which bear them.

Validity constraint: One ID per Element Type No element type may have more than one ID attribute specified.

So, one element can not have multiple ID attributes. Should we allow list of IDs?

See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jul/0091.html

Discussed at the 2003-11-14 telecon. Ashok to propose a note with a clarification

Proposed text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Nov/0060.html

If use="prohibited" and fixed are both specified, should a schema validator

1. silently ignore fixed, or
2. flag "attribute fixed and prohibited" as an error

See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jul/0122.html

Consider the following example:

<!-- other Address derivations for more countries -->
<simpleType name="USState">
 <restriction base="string">
  <enumeration value="AK">
   <annotation>lt;documentation>Alaska<documentation>lt;annotation>
  <enumeration>
  <enumeration value="AL">
    <annotation>lt;documentation>Alabama<documentation>lt;annotation>
  <enumeration>
  <enumeration value="AR">
    <annotation>lt;documentation>Arkansas<documentation>lt;annotation>
  <enumeration>
  < and so on ... -->
 <restriction>
<simpleType>

Per Part 2, http://www.w3.org/TR/xmlschema-2/#ct-enumeration

{value} A set of values from the value space of the {base type definition}.

{annotation} Optional. An annotation.

and

Mapping XML Rep to schema components,

{annotation} The annotations corresponding to all the <annotation> element information items in the [children], if any.

and

Schema Representation Constraint: Multiple enumerations

If multiple <enumeration> element information items appear as [children] of a <simpleType> the {value} of the enumeration component should be the set of all such [value]s.

This results in one enumeration component in the USState simple type component's {facets} property. That is,

enumeration

{value} = {AK, AL, AR, .. }

{annotation} = This is processor dependent.

This defect applies to enumeration and pattern schema components. This is not a critical issue and just a defect, I believe.

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

Discussed and resolved at the 2003-11-14 telecon.

The spec says "If the item is not valid, then a list." So it seems to imply that a processor needs to provide such a list if the validity is either "invalid" or "unknown". My question is: what should be provided when it is "unknown"?

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

Response from Henry: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002OctDec/0044.html

When a list valued element or attribute is used as a key then the equality of the values is important. In the following example there are 3 lists with item types "Name", "double", "nameOrDouble":

<simpleType name="l1">
  <list itemType="Name"/>
<simpleType>

<simpleType name="l2">
  <list itemType="double"/>
<simpleType>

<simpleType name="l3">
  <list itemType="tns:nameOrDouble"/>
<simpleType>

<simpleType name="nameOrDouble">
  <union memberTypes="Name double"/>
<simpleType>

Are these lists equal?

1. Items types of lists are different but item types of items are equal: <element xsi:type="l1">1.0 2.0<element> = <element xsi:type="l3">1.0 2.0<element>
2. Item types of lists are different but there are no items. <element xsi:type="l1"/> = <element xsi:type="l2"/>

What are the exact rules for comparing lists?

See: http://lists.w3.org/Archives/Public/xmlschema-dev/2002Nov/0065.html

Response from Henry: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002OctDec/0051.html

Discussed at the 2003-11-14 telecon. Ashok to follow up with pros and cons of each side of the issue.

Proposal: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Nov/0054.html

Discussed at the 2004-02-12 telecon. Decided that we need new draft text based on current 2E.

A similar question (to that of R-181) concerning equality arises with union types. Having the two union types:

<simpleType name="u1">
  <union memberTypes="string"/>
<simpleType>

<simpleType name="u2">
  <union memberTypes="string"/>
<simpleType>

are these two elements equal?

<element xsi:type="u1">abc<element> = <element xsi:type="u2">abc<element>

See: http://lists.w3.org/Archives/Public/xmlschema-dev/2002Nov/0080.html

Response from Henry: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002OctDec/0052.html

It's not clear from the spec what to do in this case. Bullet 5.2.2.2 of constraint [1] deals with default element values. 5.2.2.2.1 talks about complex types with mixed content, and 5.2.2.2.2 talks about complex types with simple type content. So there is no rule for elements with simple types.

Maybe 5.2.2.2.2 should be changed to say if the actual type is a simple type or if it's a complex type with simple type content?

[1] http://www.w3.org/TR/xmlschema-1/#cvc-elt

See the first issue raised in : http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Nov/0234.html

Response from Henry: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002OctDec/0056.html

Is it clear what string the pattern facet of a union type applies to?

It seems to me it should be the lexical space value of the winning type in the union, i.e. when processing an item with a union type, we go directly to the member type definitions, and for each one in turn:

1. normalize per the whiteSpace facet _of that member type defn_;
2. check the pattern facet of the union type itself;
3. check the pattern facet of the member type defn;
4. convert to value and check other facets from the member type defn.

If any of (2), (3) or (4) fail, go on to the next member type defn.

I don't think the REC as it currently stands makes clear that this is what happens, or that it doesn't.

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

Response from Ashok: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002OctDec/0063.html

The datatypes for recurring calendar events (specifically gMonthDay, gDay and gMonth) are all recorded in appendix A with:

<hfp:hasProperty name="cardinality" value="countably infinite"/>

However it appears that there are at most 366 days in a year, and at most 59? timezones or maybe 290000 if we take an extremist view of the possible timezones. (Alternatively, the lexical form is of finite length and comes from a finite vocabulary, hence there are finitely many different lexical forms).

Is this an oversight?

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

Discussed at the 2003-11-20 telecon. Agreed to classify as error w/erratum. Agreed to change countably infinite to finite. Ashok to draft text.

In the definitions of these facets, it says their values *must* be in the value space of the base type. But there is no constraint to enforce this rule.

For example,

<simpleType name="base">
  <restriction base="integer">
    <enumeration value="7"/>
    <enumeration value="8"/>
    <enumeration value="9"/>
  <restriction>
<simpleType>

<simpleType name="derived">
  <restriction base="my:base">
    <minInclusive value="6"/>
  <restriction>
<simpleType>

"6" in the derived type isn't from the value space of the base type, so this should be an invalid derivation, according to the definition of the minInclusive facet. But there is no constraint saying it's invalid. Section 4.3.10.4 only talks about how the minInclusive value compares with the values in the base.

IMO, all "XXX valid restriction" constraints in 4.3.7/8/9/10.4 should be replaced by a simple statement saying their values must be from the value space of the base, with the exception of min/maxExclusive, where their values could be the same as the value of the same facet in the base type.

See : http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Nov/0233.html

Discussed at the 2003-11-20 telecon. Sandy Gao to study further, to see if there is already a Rec issue that covers this

Sandy's research: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Dec/0038.html

There appear to be some rules that are implied by the spec (from some definitions, or descriptions), but there are no constraints to enforce them. Should there be?

1. Facet value from the value space of the base type. See Rec Issue R-186.

2. <schema targetNamespace="">

   The spec says "Since the empty string is not a legal namespace name, supplying an empty string for targetNamespace is incoherent, and is not the same as not specifying it at all." Does this imply the above is invalid? Or still valid? If it's valid, what would be the target namespace of components defined in this schema?

3. Fixed facet value

   In 4.3.x.1 sections, "If {fixed} is true, then types for which the current type is the {base type definition} cannot specify a value for XXX other than {value}." But there is no constraint for it.

4. Invalid pattern value

   In the definition of the pattern facet, "The value of pattern must be a regular expression." Again, there is no corresponding constraint.

5. xsi:schemaLocation has odd number of URI's

   "xsi:schemaLocation" is a list of anyURI. Each 2 of such anyURI's make a pair: one indicates the namespace, the other is a location hint. What happens if this attribute has an odd number of items? Is it an error? Or should the processor silently ignore the last item in the list?

6. Target namespace doesn't match xsi:schemaLocation or xsi:noNamespaceSchemaLocation

   What happens if the schema location hint points to a schema document with a target namespace different from what's expected? For example, what happens if the instance has

   xsi:schemaLocation="ns1 a.xsd" xsi:noNamespaceSchemaLocation="b.xsd"

   but a.xsd has a target namespace not identical to "ns1", or b.xsd has a target namespace? I suppose these are error situations, but no constraints are defined.

7. Undeclared entities

   The definition of the "ENTITY" type says "... The value space of ENTITY is ... and have been declared as an unparsed entity in a document type definition. ..." But no constraint is defined to support this rule.

8. Undeclared namespace prefixes

   The note under the definition of the "QName" type says "NOTE: The mapping between literals in the lexical space and values in the value space of QName requires a namespace declaration to be in scope for the context in which QName is used." But the spec didn't say what happens if there isn't such a namespace declaration.

See : http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Nov/0237.html

Response from Henry: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002OctDec/0057.html

1. Table 1: next to last entry (i.e., row with (0,2) -, 37) says that minOccurs is positive integer. It may also be zero.
2. Section 2.3.2 Union Types: Not clear what is meant by "singleton" in "American states being singleton letter abbreviations". The abbreviations are 2 letters long. To me, at least, singleton letter implies the abbreviations are only 1 letter long.

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

Is the following recursive definition valid?

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 		targetNamespace="http://foo.com"
 		xmlns="http://foo.com"
 		elementFormDefault="qualified">
 
 	<xsd:simpleType name="abcOrBoolean">
 		<xsd:union memberTypes="xsd:boolean abc"/>
 	<xsd:simpleType>
 
 	<xsd:simpleType name="abc">
 		<xsd:restriction base="abcOrBoolean">
 			<xsd:minLength value="5"/>
 		<xsd:restriction>
 	<xsd:simpleType>
<xsd:schema>

Henry's response:

"Not allowed. There is an erratum forthcoming which is intended to clarify this, but, irritatingly, it doesn't catch the above case. I expect yet another erratum will do so."

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

Discussed at the Feb. 7 concall. The WG agreed to classify R-189 as an error w/ erratum

Part 2: Datatypes frequently defines the lexical representation of one type as a "truncation" of that of another, without ever defining what is meant by this term. Sometimes it seems to have the conventional meaning of omitting characters from one end of a string, as in:

The lexical representation for gYear is the reduced (right truncated) lexical representation for dateTime: CCYY. [section 3.2.11.1]

Other times the omitted characters are replaced by other characters, as in:

The lexical representation for gDay is the left truncated lexical representation for date: ---DD . [section 3.2.13.1]

It's not difficult to understand what is meant, but the document overall aspires to (and for the most part handily achieves) a higher standard of precision. For consistency, I'd like to see the term defined in 1.1.

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

Discussed at the 2003-11-21 telecon. Classified as a requirement for 1.1; Ashok to add to requirements doc.

Is the following element decl valid?

<xsd:element name="Element" fixed="1.0e-2">
  <xsd:simpleType>
      <xsd:restriction base="xsd:float">
          <xsd:pattern value="...E.."/>
      <xsd:restriction>
  <xsd:simpleType>
<xs:element>

Note that 1.0e-2 doesn't satisfy the pattern, so it's not valid wrt the anonymous simple type. But "e-props-correct.2" only requires the canonical rep (not the original lexical rep) to be valid wrt the type defi, and the canonical rep of "1.0e-2" (as a float) is "1.0E-2", which does satisfy the pattern.

"Element Declaration Properties Correct" states: "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)."

And to check the above constraint, we need to have the {value constraint}'s value (an actual value). To get such actual value:

"{value constraint} If there is a default or a fixed [attribute], then a pair consisting of the actual value (with respect to the {type definition}, if it is a simple type definition, or the {type definition}'s {content type}, if that is a simple type definition, or else with respect to the built-in string simple type definition) of that [attribute] and either default or fixed, as appropriate, otherwise absent."

So it seems that we need to use the type defi to convert the original lexical rep to an actual value, then generate a canonical rep from the actual value, and use the type defi again to validate such canonical rep. Is this the intention? Is it an error if the original lexical rep is not valid?

See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Jan/0043.html

Henry's response: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0020.html

Discussed at the Feb. 7 concall. WG agreed to classify R-191 as an error w/erratum.

This mail is in response to the WG's decision on R-173.

John Mercado asked what the canonical lexical representation of duration is; the WG decided that there is no need to specify it, since there is only one lexical representation per value. This reply seems to contradict the recommendation:

If the number of years, months, days, hours, minutes, or seconds in any expression equals zero, the number and its corresponding designator may be omitted. [section 3.2.6.1]

Thus, for example, "P1Y" and "P1Y0M" are alternative lexical representations for the same value. Furthermore, according to erratum E2-23, leading zeroes are permitted in each field, making "P01Y" a third alternative.

Mercado's question is pertinent.

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

Discussed and classified at the 2003-11-21 telecon. Ashok to prepare text.

Proposed text: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Nov/0053.html

DaveP's comments: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Dec/0011.html

Consider the following example:

instance doc fragment:

     <person>
          <salary xsi:type='xs:integer'>Hello<salary>
     <person>

schema fragment:

    <xs:element name="person">
     <xs:complexType>
      <xs:sequence>
          <xs:any processContents="skip" maxOccurs='unbounded'/>
      <xs:sequence>
     <xs:complexType>
    <xs:element>

The element "salary" matches the wildcard with processContents of skip within the content model of "person". However, the element in the instance has an xsi:type specified. The question is: should a processor attempt to validate "salary" against the integer type? Schema Validity Assessment (Element) [1] would seem to indicate "yes" because clause 1.2 appears to be satisfied (via 1.2.1.2). Is this correct? If not, what did I miss? If so, was this the intention?

[1] http://www.w3.org/TR/xmlschema-1/#cvc-assess-elt

See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Nov/0281.html

Henry's response: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Nov/0290.html

Discussed at the March 13, 2003 telecon.

Suppose the instance contains:

   <person>
      <salary>
         <base xsi:type='xs:integer'>Hello<base>
         <bonus>Hello<bonus>
      <salary>
   <person>

And the relevant parts of the schema are:

    <xs:element name="person">
     <xs:complexType>
      <xs:sequence>
          <xs:any processContents="skip" maxOccurs='unbounded'/>
      <xs:sequence>
     <xs:complexType>
    <xs:element>
    <xs:element name="bonus" type="xs:integer"/>

In this case, "salary" matches the wildcard with "skip". Now, it's clear that "salary" is not assessed and no validation outcome is computed for it. I have always assumed that this means no processing of the children of such an element (such as "base" and "bonus" above), even if we can find declarations for them. I think this is implied by the definition of "skip" in Section 3.10.1 The Wildcard Schema Component [1], as well as the last note in section 5.2 Assessing Schema-Validity[2]. Is there anywhere else in the Rec this is spelled out more explicitly?

[1] http://www.w3.org/TR/xmlschema-1/#Wildcard_details

[2] http://www.w3.org/TR/xmlschema-1/#validation_outcome

Henry's response: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Nov/0291.html

Discussed and classified at the May 13, 2003 telecon.

This was formerly RQ-124.

The current description of order relation on dateTime says "A. Normalize P and Q. That is, if there is a timezone present and it is not Z....' This is incorrect; values are either timezoned or not, but they don't carry with them the information of which timezone was indicated by the original lexical representation. For dateTime, the timezone of a timezoned value is an artifact of the lexical representation, not of the value. The order is defined on the value space.

See (member-only link) http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Oct/025 8.html.

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

This was formerly RQ-127.

We request that a health warning be added at the most appropriate place in the XML Schema spec, to warn schema users against specifying whiteSpace="replace" or "collapse" on elements (and even attributes) meant to contain anything but highly constrained text such as lists, as it will not do what they think ("unexpected"!) and will in fact prevent later processing steps from doing the Right Thing.

See (member-only link) http ://lists.w3.org/Archives/Member/w3c-i18n-wg/2001Oct/0032.

Erratum text http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Apr/0269.html reviewed and approved at the May 2 telecon. To be incorporated into post 2E errata doc.

Noah has suggested that we add a health warning about whitespace processing when using Datatypes independently of Structures.

See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Dec/0006.html

and subsequent email.

[Received via private email]

The Union SimpleType Definition Schema Component is defined with the followg properties:

{member type definitions}

The appropriate case among the following:

1 If the <union> alternative is chosen, then [Definition:]define the explicit members as the type definitions resolved to by the items in the actual value of the memberTypes [attribute], if any, followed by the type definitions corresponding to the <simpleType>s among the [children] of <union> if any. The actual value is then formed by replacing any union type definition in the explicit members with the members of their {member type definitions}, in order.

2 If the <restriction> option is chosen, then the {member type definitions} of the {base type definition}.

{facets}

If the <restriction> alternative is chosen, a set of facet components constituting a restriction of the {facets} of the {base type definition} with respect to a set of facet components corresponding to the appropriate element information items among the [children] of <restriction> (i.e. those which specify facets, if any), as defined in Simple Type Restriction (Facets) (3.14.3), otherwise the empty set.

I believe that it implies a loss of facet restrictions which is highlighted by the following example:

<xsd:schema targetNamespace="http:///simple/MySchema.xsd"
    xmlns:this="http:///simple/MySchema.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <xsd:simpleType name="mySimpleType1">
        <xsd:union memberTypes="xsd:nonNegativeInteger xsd:boolean"/>
    <xsd:simpleType>
    <xsd:simpleType name="mySimpleType2">
        <xsd:restriction base="this:mySimpleType1">
            <xsd:enumeration value="true"/>
            <xsd:enumeration value="0"/>
        <xsd:restriction>
    <xsd:simpleType>
    <xsd:simpleType name="mySimpleType3">
        <xsd:union memberTypes="xsd:negativeInteger this:mySimpleType2"/>
    <xsd:simpleType>
    <xsd:simpleType name="mySimpleType4">
        <xsd:restriction base="this:mySimpleType3">
            <xsd:enumeration value="-1"/>
            <xsd:enumeration value="0"/>
            <xsd:enumeration value="1"/>
            <xsd:enumeration value="true"/>
            <xsd:enumeration value="false"/>
        <xsd:restriction>
    <xsd:simpleType>
<xsd:schema>

Since the literal value "1" and the literal value "false" are not in the value space of mySimpleType2 nor in the value space of negativeInteger, they would appear to be in error. But a literal interpretation of the definition would imply that mySimpleType3 is just a union of negativeInteger, nonNegativeInteger, and boolean and hence "1" and "false" are valid literals.

Isn't this quiet loss of explicit facet restrictions a problem?

Discussed at the April 10,2003 telecon. No decision reached.

ACTION: Paul Biron to work this out in painful detail.

[Received via private email]

In the XML representation for simpleType, final is shown as

final = (#all | (list | union | restriction)) 

This would seem to imply that only 1 of {list, union, restriction} may be specified.

However, the description of the property is as follows:

A set corresponding to the actual value of the final [attribute], if present, otherwise the actual value of the finalDefault [attribute] of the ancestor schema element information item, if present, otherwise the empty string, as follows:

the empty string

the empty set;

#all

{restriction, list, union};

otherwise

a set with members drawn from the set above, each being present or absent depending on whether the string contains an equivalently named space-delimited substring.

Given this, is it, or is it not possible to restrict 2 of {restriction, list, union}?

Resolved at the May 23, 2003 telecon that a set of values should be allowed. Classifed as error w/ erratum and editors instructed to fix the s4s and the Rec accordingly.

According to the recent discussion about list of IDs, maybe the intention was that only restriction should be considered for these types. This might be OK for ID/IDREF, but it'd be a behavior change for ENTITY/ENTITIES types. (The current wording in the datatype spec indicates that lists/unions of ENTITY are also considered as values of type ENTITY.)

See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Jan/0009.html

Discussed and resolved at the May 23, 2003 telecon. RESOLVED: direct TF to classify R-200 as error with erratum. RESOLVED: direct editors to correct the error by covering the list and union cases in the obvious may.

The link to IETF INTERNET-DRAFT: IRIs in section H.2 of the Datatypes spec is no longer correct.

Erratum E2-47 added.

In discussions of SCDs, various questions regarding the component model surfaced such as: how many components are there for particles inherited by extensions of a complextype?

"Schema Component Constraint: minExclusive valid restriction

It is an error if any of the following conditions is true:
2 maxInclusive is among the members of {facets} of {base type definition} and {value} is greater the {value} of the parent maxInclusive"

So it's an error for minEx > base.maxIn, which implies minEx <= base.maxIn (if minEx == maxIn, it results in an empty value space)

"Schema Component Constraint: maxExclusive valid restriction

It is an error if any of the following conditions is true:
3 minInclusive is among the members of {facets} of {base type definition} and {value} is less than or equal to the {value} of the parent minInclusive"

So it's an error for maxEx <= base.minIn, which implies maxEx > base.minIn

Isn't this inconsistent? Shouldn't this be either:

minEx < base.maxIn && maxEx > base.minIn
or
minEx <= base.maxIn && maxEx >= base.minIn

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0037.html

What is the content type of the following?

<complexType>
  <sequence min=max=0>
    <element .../>

According to the complexType complexContent mapping rules, because there IS a sequence with an element child, the effective content is not empty, but is the particle corresponding to the sequence. But according to section 3.8.2, min=max=0 corresponds to no component at all.

Shouldn't 2.1.1 of the definition of effective content in the mapping rules (of 2nd edition) be changed to:

2.1.1 There is no <group> <all> <choice> or <sequence> among the [children], which either doesn't have a maxOccur attribute, or the actual value of such attribute is not 0.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0038.html

Is this allowed? ("mixed" appears on both complexType and complexContent.)

<complexType name="ct" mixed="true">
  <complexContent mixed="false">

There doesn't appear to be any constraint saying it's not allowed.

Assuming it's allowed, the mapping rules for complexType complexContent in 2E state:

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

Now both 1 and 2 apply. Which one should be used? (I think the intention is that "mixed" on <complexContent> takes precedence. In that case, we at least need an "otherwise" in clause 2 above.)

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

HT: Identity constraints are described as applying to "an element or attribute node with a simple type", but it's not clear from this whether an element with a simpleContent complex type is OK (which it should be, in my opinion).

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0049.html

Resolved at the 2003-09-10 telecon to classify as clarification w/erratum, clarifying that the use of simple type is intended to also cover simpleContent.

Is the following restriction valid:

 
 BASE: 

 <xs:sequence minOccurs="0" maxOccurs="1"> 
   <xs:any namespace="##any" processContents="skip" minOccurs="1" maxOccurs="unbounded"/>
 <xs:sequence> 
 
 DERIVED: 
 <xs:sequence minOccurs="0" maxOccurs="1"> 
       <xs:element name="A" minOccurs="1" maxOccurs="unbounded" /> 
       <xs:element name="B" minOccurs="1" maxOccurs="unbounded" /> 
 <xs:sequence>

From Schema Component Constraint: Particle Derivation OK (All:All,Sequence:Sequence -- Recurse)

2 There is a complete order-preserving functional mapping from the particles in the {particles} of R to the particles in the {particles} of B such that all of the following must be true: ...

[Definition:] A complete functional mapping is order-preserving if each particle r in the domain R maps to a particle b in the range B which follows (not necessarily immediately) the particle in the range B mapped to by the predecessor of r, if any, where "predecessor" and "follows" are defined with respect to the order of the lists which constitute R and B. "

See the following for Henry's answer and subsequent thread http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0057.html

See also the following related mail: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003OctDec/0023.html and http://lists.w3.org/Archives/Public/xmlschema-dev/2003Oct/0026.html

And, see the following related mail: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0037.html and http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0044.html

Section 3.2.19 of the datatypes spec states:

"[Definition:] NOTATION represents the NOTATION attribute type from [XML 1.0 (Second Edition)]. The value space of NOTATION is the set QNames of notations declared in the current schema. The lexical space of NOTATION is the set of all names of notations declared in the current schema (in the form of QNames)."

Note that the "lexical space" is "the set of all names of notations declared ..." Here "lexical space" is a set of strings, but "names of notations" are QNames, which are not strings (and they don't/can't give strings either, because QNames don't have canonical reps).

IMO, since "the set of QNames of notations declared" is already mentioned for the value space of NOTATION, it's sufficient to say "the set of strings that match the QName production of [Namespaces in XML]" for the lexical space.

Erratum E2-34 did clarify NOTATION's value space, but this issue was not covered.

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

All schema components have an id attribute, but the two children of annotation (appinfo and documentation) haven't. Why?

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0075.html

The following is Paul Biron's translation of the original comment (which was in French):

Allow me make a small comment regarding the XML Schema Part 0: Introduction available at the URL http://xmlfr.org/w3c/TR/xmlschema-0/.

In Chapter 2.2, one can read (just after the definition of the type USAddress) "The consequence of this definition is that all instances of this element in an instance (for example shipTo in the file po.xml) must consist of 5 elements and one attribute.

Also in the same chapter 2.2 (just after the definition of the type PurchaseOrderType): "The elements shipTo and billTo may equally have a country attribute which is part of the definition of USAddress."

In the first case shipTo MUST have the attribute, in the second case, shipTo MAY have the attribute. This is a X significant difference [trans: I can't find a translation of reelle...it might be a typo] . (I have seen the English version, and it has the same ambiguity).

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

The {attributes} property on the Annotation schema component is described as "A sequence of attribute information items, namely those allowed by the attribute wildcard in the type definition for the <annotation> item itself or for the enclosing items which correspond to the component within which the annotation component is located."

http://www.w3.org/XML/Group/2002/09/xmlschema-1/structures-with-errata.html#cAnnotations

http://www.w3.org/XML/Group/2002/09/xmlschema-1/structures-with-errata.html#declare-annotation

The XML Information Set spec, on the other hand, defines the [attributes] property of element information items as containing a set, not a sequence, of attribute information items.

http://www.w3.org/TR/xml-infoset/#infoitem.element

I think the XML Schema spec should probably similarly specify a set, not a sequence, of attribute information items.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0089.html

Clause 5.1.1 of Validation Rule: Element Locally Valid (Element), in Structures section 3.3.4, reads

5.1.1 If the actual type definition is a local type definition then the canonical lexical representation of the {value constraint} value must be a valid default for the actual type definition as defined in Element Default Valid (Immediate) (3.3.6).

Two questions:

1 is there not a term we can use for xsi:type-specified types which is less subject to misunderstanding than 'local type definition'? The types denoted here by this phrase are not local to a given element declaration, and it just seems like offering a pawn to fate to use the word 'local' here. Call them 'dynamic', call them 'instance-specified', call them 'types with polka dots', but is it really essential to call them 'local'?

2 Clause 5.1.1 seems to suggest that it's only an error for an element instance to require / use a default value if the element instance has an xsi:type attribute. I think this is probably because the other case is catered for somewhere else, but I think it's a needless complication. I think clause 5.1.1 can and should be simplified to say:

5.1.1 The canonical lexical representation of the {value constraint} value must be a valid default for the actual type definition as defined in Element Default Valid (Immediate) (3.3.6).

I think this is easier to understand both syntactically and from a design point of view. Is there any reason not to change it?

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0002.html

Henry's response: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0003.html

This is a recap of an possible erratum discussed within the Schema IG.

Because attribute wildcards have a "lazy" behavior, it's possible for an apparently-valid restriction to violate the general notion of restriction. By "lazy" I mean the property that an attribute-wildcard will only match an attribute-information-item (AII) if no other attribute-use matches the AII.

Best demonstrated by example:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

   <xs:complexType name="B">
     <xs:attribute name="FOO" type="xs:int"/>
     <xs:anyAttribute processContents="skip"/>
   </xs:complexType>

   <xs:complexType name="A">
     <xs:complexContent>
       <xs:restriction base="B">
         <xs:attribute name="FOO" type="xs:int" use="prohibited" />
         <xs:anyAttribute processContents="skip" />
       </xs:restriction>
     </xs:complexContent>
   </xs:complexType>

 </xs:schema>

I believe this is a valid restriction per the rules of restriction, but not by the general definition in Section 2, which includes

Members of a type, A, whose definition is a restriction of the definition of another type, B, are always members of type B as well.

B doesn't accept an element with attribute FOO="abc", but A does accept it. That's because A doesn't contain an attribute-use for FOO, so the attribute-wildcard validates FOO in A.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0007.html

[Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point type [IEEE 754-1985]. The basic value space of double consists of the values m 2^e, where m is an integer whose absolute value is less than 2^53, and e is an integer between -1075 and 970, inclusive. ...

It seems to me that "e" should be an integer between -1074 and 971, inclusive.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0022.html

Response from Xan: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0027.html

Resolved at the 2003-08-29 telecon to classify as an error, and to instruct the editors to fix the error in the manner discussed on the email thread.

According to the errata: http://www.w3.org/2001/05/xmlschema-errata.html#e1-6 whitespace is now allowed between tokens in xpaths.

The patterns in the schema for schema have not been updated to reflect this.

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

Discussed at the 2003-08-31 telecon to classify as an error with erratum, and instruct the editors to fix the pattern.

The constraint for NameAndTypeOK is as follows:

Schema Component Constraint: Particle Restriction OK (Elt:Elt -- NameAndTypeOK)

For an element declaration particle to be a valid restriction of another element declaration particle all of the following must be true:
1 The declarations' {name}s and {target namespace}s are the same.
2 Either B's {nillable} is true or R's {nillable} is false.
3 R's occurrence range is a valid restriction of B's occurrence range as defined by Occurrence Range OK (3.9.6).
4 either B's declaration's {value constraint} is absent, or is not fixed, or R's declaration's {value constraint} is fixed with the same value.
5 R's declaration's {identity-constraint definitions} is a subset of B's declaration's {identity-constraint definitions}, if any.
6 R's declaration's {disallowed substitutions} is a superset of B's declaration's {disallowed substitutions}.
7 R's {type definition} is validly derived given {extension, list, union} from B's {type definition} as defined by Type Derivation OK (Complex) (3.4.6) or Type Derivation OK (Simple) (3.14.6), as appropriate. 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.

Some issues:
- It's not mentioned what's B and what's R. The first sentence should be modified to something similar to "For an element declaration particle R to be a valid restriction of another element declaration particle R all of the following must be true:".
- Since B and R are particles, bullets 2 and 7 are not correct in saying B's {nillable} or R's {type definition}. I think the first sentence can be further modified to "For a particle R whose {term} is an element declaration RE to be a valid restriction of another particle B whose {term} is an element declaration BE all of the following must be true:", then use RE and BE in the proper places.

Proposed text:

Schema Component Constraint: Particle Restriction OK (Elt:Elt -- NameAndTypeOK)

For a particle R whose {term} is an element declaration RE to be a valid restriction of another particle B whose {term} is an element declaration BE all of the following must be true:
1 RE and BE have the same {name}s and {target namespace}s.
2 Either BE's {nillable} is true or RE's {nillable} is false.
3 R's occurrence range is a valid restriction of B's occurrence range as defined by Occurrence Range OK (3.9.6).
4 Either BE's {value constraint} is absent, or is not fixed, or RE's {value constraint} is fixed with the same value.
5 RE's {identity-constraint definitions} is a subset of BE's {identity-constraint definitions}, if any.
6 RE's {disallowed substitutions} is a superset of BE's {disallowed substitutions}.
7 RE's {type definition} is validly derived given {extension, list, union} from BE's {type definition} as defined by Type Derivation OK (Complex) (3.4.6) or Type Derivation OK (Simple) (3.14.6), as appropriate. 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.

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0046.html

In the constraint "Derivation Valid (Restriction, Complex)"

2.1.3 [Definition:] Let the effective value constraint of an attribute use be its {value constraint}, if present, otherwise its {attribute declaration}'s {value constraint} . Then one of the following must be true:
2.1.3.1 B's effective value constraint is absent or default.
2.1.3.2 R's effective value constraint is fixed with the same string as B's.

2.1.3.2 mentions "the same string as B's". Shouldn't it be either the same "actual value" or the same "canonical representation"? (I think actual value is more proper.)

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

Consider

<complexType name="derived" mixed="false">
 <complexContent mixed="false">
  <extension base="base"/>
 </complexContent>
</complexType>

where "base" is a complex type whose {content type} is a simple type definition.

Then according to structure 3.4.2, "derived" has the same content type as base, which is a simple type definition. But it specified <complexContent> explicitly, and mixed = false. This seems confusing.

And if mixed was true on <complexType> and <complexContent> then the rule actually says that "derived" has a content of a sequence of an empty sequence, following the particle from "base". But "base" doesn't have a particle. (Rules from 3.4.6 says this is invalid, but those are at the component level. Here we are talking about the mapping.)

IMO, <complexContent> shouldn't be allowed to extend a complex type with simple content. That is, change bullet 1 of the constraint "Complex Type Definition Representation OK" [1] to

1 If the <complexContent> alternative is chosen, then all of the following must be true:
1.1 The type definition resolved to by the actual value of the base [attribute] must be a complex type definition;
1.2 If the <extension> alternative is also chosen, then the type definition resolved to by the actual value of the base [attribute] must not be a complex type definition whose {content type} is a simple type definition;

[1] http://www.w3.org/XML/Group/2002/09/xmlschema-1/structures-with-errata.html#src-ct

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0048.html

HT proposed a resolution to R-218 which was discussed at the 2003-10-10 telecon. Proposed errata text approved (but the WG allows him to edit the text to express it more formally).

At the 2003/11/20 telecon, the following question arose:

Does section 3.11.1 of Structures need to explicitly cover lists and unions?

See: http://www.w3.org/2003/11/20-xmlschema-irc#T17-22-00

E1-17 changes the definition of Type Derivation OK (Complex) and Type Derivation OK (Simple) to require the type defns being checked to be named.

This change results in an unintended and negative side-effect, namely that anonymous types can't be used at all, even for top-level element declarations.

So for example, the following derivation is _not_ conformant any more:

<xs:element name="elt">
 <xs:simpleType>
  <xs:restriction base="xs:string"/>
 <xs:simpleType>
<xs:element>

<xs:complexType name="base">
 <xs:sequence>
  <xs:element ref="elt" minOccurs="0"/>
 <xs:sequence>
<xs:complexType>

<xs:complexType name="derived">
 <xs:complexContent>
  <xs:restriction base="base">
   <xs:sequence>
    <xs:element ref="elt"/>
   <xs:sequence>
  <xs:restriction>
 <xs:complexContent>
<xs:complexType>

See: http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2003Dec/0000.html

Are implementations expected to handle decimal values with > 18 digits? And, since unsignedLong is derived from decimal, should the minimum number of digits supported be 20 instead?

See: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Dec/0025.html

Note: this relates to issues raised in R-90.

Discussed at the 2003/12/19 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Dec/0064.html

This issue was raised at the May 2003 f2f. See: (http://www.w3.org/XML/Group/2003/05/xml-schema-ftf-minutes#d0e750

XML Schema Part 2 suggests that the XMLSchema-datatypes URI is an alias for the xmlschema namespace URI:

"To facilitate usage in specifications other than the XML Schema definition language, such as those that do not want to know anything about aspects of the XML Schema definition language other than the datatypes, each built-in datatype is also defined in the namespace whose URI is: http://www.w3.org/2001/XMLSchema-datatypes "

while the documentation in the schema for the XMLSchema-datatypes suggests a different relationship, which is consistent with the notion of one-name-per-component:

<documentation>Note this schema is NOT a normative schema - - It contains types derived from all the builtin simple type definitions with the same local name but in a distinct namespace, for use by applications which do no wish to import the full XMLSchema schema. Since derivation is not symmetric, unexpected results may follow from mixing references to these definitions with references to the definitions in the XMLSchema namespace. For example, although dt:positiveInteger is derived from xs:integer, the converse does not hold.<documentation>

A minor comment concerning "XML Schema Part 1, 3.14, Example": from a physical viewpoint, should the name "farenheitWaterTemp" not better be "celsiusWaterTemp"?

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0056.html

Appendix F in the Part 2 of XML Schema 1.0 defines 'metacharacter' thus:

A metacharacter is either ., \, ?, *, +, {, } (, ), [ or ].

It defines 'normal character' thus:

[Definition:] A normal character is any XML character that is not a metacharacter. In regular expressions, a normal character is an atom that denotes the singleton set of strings containing only itself.

Production [10], which I take to be defining normal characters, reads:

Normal Character [10] Char ::= [^.\?*+()|#x5B#x5D]

The metacharacters all need escapes, so production 24 is also relevant here:

Single Character Escape [24] SingleCharEsc ::= '\' [nrt\|.?*+(){}#x2D#x5B#x5D#x5E]

I have some questions:

1. shouldn't { and } (braces) be included in production [10]? ? [10] Char ::= [^.\?*+{}()|#x5B#x5D]
2. shouldn't | (vertical bar) be among the characters defined as metacharacters?
3. should ^ (#x5E) be included among the metacharacters?
4. would it be possible to list the magic characters in the same order in 10 and 24, to make eyeball-based comparisons easier?

I suspect the answer to (2) is 'yes' and the answer to (3) is 'no, on the theory that the term 'metacharacter' is best reserved for characters which have special meaning at the top level of a regular expression and which must therefore have escapes to avoid ambiguity. Hyphen, circumflex, comma, n, r, and t all have special meaning only in special contexts (within character groups, within quantity-range specifications, or after backslash), and so aren't metacharacters in this sense.

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

Note that items 1 and 2 are covered by R-41.

It's not clear from the spec what to do in this case: Bullet 5.2.2.2 of [1] deals with default element value. 5.2.2.2.1 talks about complex type with mixed content, and 5.2.2.2.2 talks about complex type with simple type content. So there is no rule for elements with simple types.

Perhaps 5.2.2.2.2 should be changed to say if the actual type is a simple type or if it's a complex type with simple type content?

[1] http://www.w3.org/TR/xmlschema-1/#section-Element-Declaration-Validation-Rules

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

With respect to the schemaLocation attribute of import, he REC says "It is not an error for the application schema reference strategy to fail." It says something similar for the schemaLocation attribute of include and redefine. It _doesn't_ say this wrt xsi:schemaLocation, but I believe it is reasonable to carry the above over to this case.

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

If an element selected by the field of an identity constraint has xsi:nil='true', is the value treated as missing? For example, is the following instance valid, given the schema.

schema
------
<xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
         <xsd:element name="root">
                 <xsd:complexType>
                         <xsd:sequence>
                                 <xsd:element ref="uid" maxOccurs="unbounded"/>
                         </xsd:sequence>
                 </xsd:complexType>
                 <xsd:unique id="foo123" name="uuid">
                         <xsd:selector xpath=".//uid"/>
                         <xsd:field xpath="."/>
                 </xsd:unique>
         </xsd:element>
         <xsd:element name="uid" nillable="true" type="xsd:anySimpleType"/>
</xsd:schema>

instance
--------
<xml version="1.0"?>
<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xsi:noNamespaceSchemaLocation="idF018.xsd">
         <uid xsi:nil="true" xsi:type="xsd:string"/>
         <uid xsi:nil="true"/>
</root>

I think this should be valid since the xsi:nil attribute on the uid elements would be equivalent to the elements missing for the purposes of identity constraints. Either way 3.11.4 of Schema part 1 could use some clarification around xsi:nil.

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

The value of totalDigits at the example [1]

<simpleType name='celsiusBodyTemp'>
  <restriction base='decimal'>
    <totalDigits value='4'/>
    <fractionDigits value='1'/>
    <minInclusive value='36.4'/>
    <maxInclusive value='40.5'/>
  </restriction>
</simpleType>

should probably be 3 -- if at all present. The presence of both minInclusive and maxInclusive make totalDigits superfluous. The fractionDigits set to 1 means that only one digit after the decimal point is allowed.

Considering the other three facets all valid values have at max 3 digits.

Also ,the magnitude of a (live) person's body temperature on the Celsius scale would probably go up to 42 Celsius...

[1] http://www.w3.org/TR/2004/PER-xmlschema-2-20040318/#rf-fractionDigits

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

Several readers have found that section 3.8 of XML Schema 1.0 Part 2 leaves some uncertainty as to the exact nature of the order relation on time values. The text says:

Since the lexical representation allows an optional time zone indicator, time values are partially ordered because it may not be able to determine the order of two values one of which has a time zone and the other does not. The order relation on time values is the Order relation on dateTime (section 3.2.7.3) using an arbitrary date. See also Adding durations to dateTimes (appendix E). Pairs of time values with or without time zone indicators are totally ordered.

Here is an example that illustrates the potential for misinterpretation. Two different answers are possible to a given ordering question, depending on how the specification is interpreted.

Question: Is 09:00:00+12:00 < 09:00:00-12:00?

It seems clear that the correct answer is no, since section 3.2.8 of XML Schema 1.0 Part 2 says "time represents an instant of time that recurs every day". These two time values are 24 hours apart, so they should be equal. But some interpretations of the order relation for time values produces different answers.

Answer 1:

Step 1: Assign an arbitrary date to both time values:
Is dateTime 2002-02-16T09:00:00+12:00 < 2002-02-16T09:00:00-12:00?
Step 2: Apply the Order relation on dateTime:
Step 2A: Since both dateTimes contain a timezone, normalize them to Z: Is dateTime 2002-02-15T21:00:00Z < 2002-02-16T21:00:00Z?
Step 2B: Since both dateTimes contain a timezone, compare P and Q field by field from the year field down to the second field. Since the day field of the first value (15) is less than the day field of the second value (16), the answer is true (that is, the first time value is less than the second one).

Answer 2:

Step 1: Normalize the time values to Z:
Is 21:00:00Z < 21:00:00Z?
Step 2: Assign an arbitrary date to both time values: Is dateTime 2002-02-16T21:00:00Z < 2002-02-16T21:00:00Z?
Step 3: Apply the Order relation on dateTime:
Step 3A: Since both dateTimes contain a timezone, normalize them to Z:
No change.
Step 3B: Since both dateTimes contain a timezone, compare P and Q field by field from the year field down to the second field. Since all fields in the values are identical, the answer is false (the first time value is not less than the second one).

As stated above, I believe that the second answer (and the second algorithm) is correct. It must be, otherwise the definition of time values would be violated (because these two time values which are clearly identical under the definition of the type would not be equal under the order relation).

However, the algorithm I described for calculating answer 2 above is not easily inferred from the specification. The specification says "The order relation on time values is the Order relation on dateTime (section 3.2.7.3) using an arbitrary date." We believe that this means that for time values with time zones, you must normalize the dates into a single 24 hour period before applying the Order relation on dateTime. An easy way to do this is to normalize the time values to UTC and then assign an arbitrary year-month-day value to them. But a more natural interpretation of the spec would be to skip the normalization step and just assign the year-month-day value. This will probably work just fine until you encounter a situation like the one given above. We ran into this while working on an XACML implementation (which uses the XML Schema ordering for time values).

We suggest adding text to the XML Schema specification to make it easier for implementors to understand the proper interpretation of the spec. After the sentence that ends with "using an arbitrary date", we would suggest adding a sentence that says "Before assigning this arbitrary date, time values with a time zone must be normalized to UTC."

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

Please clarify an issue regarding the use of maxOccurs="0", particularly within a type derived by <restriction>

From various places in the Structures recommendation I have gathered the following information:

1. Where minOccurs=maxOccurs=0, the item "corresponds to no component at all." [repeated]

2. The Particle Schema Component: {max occurs} - "Either a non-negative integer or unbounded." http://www.w3.org/TR/xmlschema-1/#p-max_occurs

3. Particle Correct: for all particles "{max occurs} must be greater than or equal to 1." http://www.w3.org/TR/xmlschema-1/#p-props-correct

Also, from the Primer:

4. An element with minOccurs="0" and maxOccurs="0" means the element "must not appear." http://www.w3.org/TR/xmlschema-0/#cardinalityTable

5. In restriction, minOccurs="0" and maxOcurs="0" means "exclusion of an optional component." http://www.w3.org/TR/xmlschema-0/#restrictsTable

It seems to me that (2) and (3) conflict. (2) effectively says that a particle may have maxOccurs="0" while (3) says this would not be a correct particle. Is an incorrect particle still a particle?? I'm not sure that (1) excuses this conflict. Looking at the Errata I cannot see any substantive changes to these definitions.

The problem I have specifically relates to restriction of a complexType containing a sequence. As I understand it, the derived restricted sequence can either simply not mention the element I wish to 'prohibit' or can explicitly prohibit it by specifying maxOccurs="0" and this should mean the same thing. However, (3) implies that the latter would not validate.

E.g.

   <complexType name="base">
     <sequence>
       <element name="a" minOccurs="0" maxOccurs="1"/>
       <element name="b" minOccurs="0" maxOccurs="1"/>
       <element name="c" minOccurs="0" maxOccurs="1"/>
     </sequence>
   </complexType>

   <complexType name="deriveByOmission">
     <complexContent>
       <restriction base="base">
         <sequence>
           <element name="a" minOccurs="0" maxOccurs="1"/>
           < prohibit element "b" by omission -->
           <element name="c" minOccurs="0" maxOccurs="1"/>
         </sequence>
       </restriction>
     </complexContent>
   </complexType>

   <complexType name="deriveByZeroOccurrence">
     <complexContent>
       <restriction base="base">
         <sequence>
           <element name="a" minOccurs="0" maxOccurs="1"/>
           <element name="b" minOccurs="0" maxOccurs="0"/> <!-- prohibit
element "b" -->
           <element name="c" minOccurs="0" maxOccurs="1"/>
         </sequence>
       </restriction>
     </complexContent>
   </complexType>

(Helpfully, of the seven schema tools I've tried, 5 accept both derivations (but given other experiences are maybe just too lax) and 2 refuse both...)

Which of these 2 derivations are correct?

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

The prose in parts 1 and 2 wrt the components which result from a pair of type definitions such as:

Example:

<xs:simpleType name="A">
 <xs:restriction base="xs:token">
  <xs:enumeration value="x"/>
  <xs:enumeration value="y"/>
  <xs:enumeration value="z"/>
 </xs:restriction>
</xs:simpleType>

<xs:simpleType name="B">
 <xs:restriction base="A">
  <xs:enumeration value="y"/>
 </xs:restriction>
</xs:simpleType>

is not clear at all.

Does the {facets} property of B contain:

1 - One enumeration component whose {value} is {y}?
2 - One enumeration component whose {value} is {x, y, z}?
3 - Two enumeration components whose {value}s are {y} and {x, y, z}?

This need to be cleaned up once and for all.

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

In June 2003, the XML Schema WG briefly discussed cases like the following:

XSD1:
<schema ...>
<complexType name="CT">
...
</schema>

XSD2:
<schema ...>
<redefine schemaLocation="XSD1">
<!-- CT in XSD2 is vacuous restriction of CT in XSD1 *-->
<complexType name="CT">
 <restriction base="CT"/>
</complexType>
</redefine>
</schema>

XSD3:
<schema ...>
<import schemaLocation="XSD1"/>
<import schemaLocation="XSD2"/>
</schema>

Several questions arise:

1. is this legal or not, in XML Schema 1.0?
2. regardless of the answer to (1), SHOULD this be legal in XML Schema?

One position one could take is that since the CT of XSD1 and the CT of XSD2 are as similar as one can make them (same name, same extension), the double import really should be legal.

Another possible position is that if one wanted them to be identical one would not have redefined CD in XSD2 -- just as vacuous restrictions can be used to block certain substitutions by imposing a certain structure on the type hierarchy, so the vacuous restriction here should be allowed, and should not be treated differently from a non-vacuous restriction.

When this came up in June, some WG members offered an analysis of this case which led them to conclude that the example is not legal; I never understood the details. Can anyone expound?

Depending on what the WG decides to do, this topic might turn into an error report on 1.0 or a requirement for 1.1, or a no-action-needed.

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

An issue is in order to clarify that the four [xsi:] attributes must be validated using the built-in declarations whenever they appear, and must be valid, and get PSVI-only properties. This will require an extra clause in Element Locally Valid (Complex Type), and possibly in Schema Information Set Contribution: Assessment Outcome (Attribute).

For additional info and background, see: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JulSep/0073.html

Is the following schema valid?

        <xsd:element name="elem1">
 		<xsd:complexType/>
 	</xsd:element>

 	<xsd:complexType name="type1">
 		<xsd:sequence>
 			<xsd:element ref="elem1"/>
 			<xsd:element ref="elem1"/>
 		</xsd:sequence>
 	</xsd:complexType>

Henry's response:

Should be, but the REC language is broken here -- I'm pretty sure the intent was for this constraint to apply to two _distinct_ element declarations, which means at least one of them would have to be local, as all refs to a named top-level element decl produce the _same_ element decl. I'm not aware of any processors which complain about this case.

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

If I understand the specs correctly, the canonical form of the decimal -0.0 is -0.0, but I would expect it to be 0.0. I scanned through the errata but couldn't find anything that's related to this. Is this an error in the XML Schema datatypes spec?

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

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

From the datatypes spec:

"integer has the following constraining facets:
...
whiteSpace
..."

and...

"[Definition:] A constraining facet is an optional property that can be applied to a datatype to constrain its value space."

So, does the whitespace facet constrain the *value space* of integer somehow?

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

See also this related comment: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003OctDec/0022.html

The following are a few things that look like errors in the current schema-for-schema posted on http://www.w3.org/2001/XMLSchema.xsd

Some of them have been discussed here in the past or even mentioned in the errata, but don't seem to be reflected in the posted xsd.... They are all minor things, but they all do get in the way of actually using the schema-for-schema to validate schemas. Here is my list of changes:

1. finalDefault needs to permit "list" and "union"
2. the type of the <element> element in an <all> group needs to be given a name so that it is legal to use the type in both a base type and a restriction when using the allModel (otherwise it breaks one of the particle-valid (restriction) rules).
3. The regular expressions that describe integrity constraint xpaths need to be modified to permit whitespaces in certain places, as discussed in one of the errata.

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

In Section 2.5.3 Empty Content - 2nd paragraph in the XML Schema Part 0: Primer document published on May 2, 2001, I have identified the following error.

I think the following line:

Such an element has no content at all; its content model is empty. To define a type whose content is empty, we essentially define a type that allows only elements in its content, but we do not actually declare any elements and so the type's content model is empty:

should be read as:

Such an element has no content at all; its content model is empty. To define a type whose content is empty, we essentially define a type that allows only attributes in its content, but we do not actually declare any elements and so the type's content model is empty:

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

Priscilla's response: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003OctDec/0020.html

The Element Declarations Consistent rule for model groups ( http://www.w3.org/TR/xmlschema-1/#cos-element-consistent) rules out inconsistent element declarations like the following two conflicting definitions of element <a> i.e., <a> cannot be both an "int" and a "string" in the same group:

(example-1)
<xs:complexType name="example-1">
  <xs:sequence>
    <xs:element name="a" type="xs:int"/>
    <xs:element name="whatever"/>
    <xs:element name="a" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

In addition to explicit element declarations, the rule also prevents conflicts between elements that appear "either directly, indirectly, or implicitly", i.e., between nested model groups or elements permitted via substitution groups.

My question: consider the following "tricky" indirect case involving a wildcard referencing a global element -

(example-2)
<xs:element name="a" type="xs:string"/>
<xs:complexType name="example-2">
  <xs:sequence>
    <xs:element name="a" type="xs:int"/>
    <xs:element name="whatever"/>
    <xs:any namespace="##targetNamespace" processContents="lax"/>
  </xs:sequence>
</xs:complexType>

Clearly the local <a> and the indirect reference to the global <a> are "inconsistent" with each other within the content model of example-2, but I'm not sure if the "directly, indirectly, or implicitly" language in the ETC rule captures this case.

Is there a hole in the EDC rule language with respect to example-2? Is this something that could be clarified in an errata?

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

Henry's response: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003OctDec/0030.html

Also, see follow-up mail re: potential other EDC issues: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003OctDec/0060.html

I think the following passage in Part 1 is wrong:

Schema Component Constraint: Particle Derivation OK (All/Choice/Sequence:Any -- NSRecurseCheckCardinality)

For a group particle to be a valid restriction of a wildcard particle all of the following must be true:

1 Every member of the {particles} of the group is a valid restriction of the wildcard as defined by Particle Valid (Restriction) (3.9.6).

[...]

If understood literally, this is saying that a particle of a model group can be a valid restriction of a wildcard. How can a particle be a valid restriction of a **wildcard** (as opposed to a **particle whose term is a wildcard**)?

If, instead, I interpret it as:

"1 Every member of the {particles} of the group is a valid restriction of the wildcard **particle** as defined by Particle Valid (Restriction) (3.9.6)." it becomes clearly wrong, given that the min occurs and max occurs of the "base" particle and the min occurs and max occurs of the "restricted" particle have a role in determining whether a "restricted" particle (say, an element declaration particle) is a valid restriction of a "base" particle (say, a wildcard particle).

For example, suppose I want to restrict a wildcard particle (min occurs=4, max occurs=8) with a sequence particle whose term has three element declaration particles. The statement above would require that **each** of the element declaration particles was a valid restriction of the wildcard particle, which in turn implies that **each** of the element declaration particles had to have min occurs>=4, max occurs<=8 (see 3.9.6, Schema Component Constraint: Particle Derivation OK (Elt:Any -- NSCompat)). This makes no sense.

A possible correction is rewording the sentence as follows:

1 Every member of the {particles} of the group is a valid restriction of the wildcard particle as defined by Particle Valid (Restriction) (3.9.6), except that the min occurs of the wildcard particle must be replaced by 0 before applying Particle Valid (Restriction) (3.9.6).

or perhaps as follows:

1 Every member of the {particles} of the group is a valid restriction (as defined by Particle Valid (Restriction) (3.9.6)) of a particle constructed as follows:
min occurs: 0
max occurs: the same as the max occurs of the wildcard particle
term: the wildcard

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

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0000.html

It seems to me that the the following schema should be invalid because the value space of the base type definition of the element "e" in the type "ct-base" is not a super set of the value space of the base type definition of the element "e" in "ct-deriv"; but I cannot find any Schema Component Constraint invalidating it.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:simpleType name="base">
    <xs:union memberTypes="xs:boolean xs:integer"/>
  </xs:simpleType>

  <xs:simpleType name="deriv">
    <xs:restriction base="base">
      <xs:enumeration value="1"/>
      <xs:enumeration value="2"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:complexType name="ct-base">
    <xs:sequence>
      <xs:element name="e" type="deriv"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="ct-deriv">
    <xs:complexContent>
      <xs:restriction base="ct-base">
        <xs:sequence>
          <xs:element name="e" type="xs:integer"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

</xs:schema>

Using cos-st-derived-ok [1], xs:integer seems to be validly derived given {extension, list, union} from deriv (because the member type definitions property of deriv is the the member type definitions of base). Therefore, rcase_NameAntTypeOK [2] is not violated, and the restriction seems to be valid.

Comment originally posted to xmlschema-dev mail list.

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

Section 3.14.1 says the {final} property of simpleType is:

A subset of {extension, list, restriction, union}.

I would expect it to say:

A subset of {list, restriction, union}.

Section 3.14.2 gives the syntax of the final attribute as:

final = (#all | (list | union | restriction))

I would expect it to be:

final = (#all | List of (list | union | restriction))

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

Note: the second part of this comment is covered by R-199.

The REC says in clause 1.5 of Schema Component Constraint: Derivation Valid (Extension):

Note: This requirement ensures that nothing removed by a restriction is subsequently added back by an extension.

That is where the REC tries to answer "no" to the question of "whether an attribute [or element] removed by restriction could be added back in an extension." However the constraint itself, in my view, fails to achieve this, so processors which allow it are not broken.

I think we should fix this one way or another:

1. No constraint on re-introduction;
2. No re-introduction of any kind (apparent intention of current REC);
3. Re-introduction of unchanged originals only (what the current REC actually says)?

See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0005.html

See subsequent email on this thread.

The XSD builtin datatypes, gMonthDay and time, are missing from the sentence "This appendix also addresses the additions of durations to the datatypes ......". Since Section 3.2.12 gMonthDay and Section 3.2.8 time contain a reference to Appendix E, one would conclude they should also be listed in this sentence to confirm that the add duration algorithm also applies to these two types.

For more details, see: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0038.html

http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0039.html

Section 3.1.4 states:

"The language used is as if the correspondences were mappings from XML representation to schema component, but the mapping in the other direction, and therefore the correspondence in the abstract, can always be constructed therefrom."

Above is the original text. I suspect that the following is what was meant :

"The language used is as if the correspondences were mappings from XML representation to schema component, but the mapping _is_ in the other direction, and therefore the correspondence in the abstract__ can always be constructed therefrom."

My changes are delimited by '_'. ( Added 'is' and removed comma. )

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0050.html

The Errata for Part 2 (Datatypes) seems to use the term space instead of whitespace,
e.g. in E2-30 Clarification.

Thus the definition of IDREFS should also use the term space.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0056.html

The errata for the language data type in http://www.w3.org/TR/2004/PER-xmlschema-2-20040318/datatypes-with-errata.html#language contains an error in the pattern definition. The closing round bracket is missing:

The lexical space of language is the set of all strings that conform to the pattern ([a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0070.html

Parenthesis vs brace at S{,m)

Note: The regular expression language in the Perl Programming Language [Perl] does not include a quantifier of the form S{,m), since it is logically equivalent to S{0,m}

Unclosed parenthesis started at:

The lexical space of base64Binary is given by the following grammar (the notation is that used in [XML 1.0 ...

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0065.html

The commentator objects to the regular expression grammar change in E2-18. For more details see: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0075.html

See also: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004AprJun/0018.html

My comments relate to

http://www.w3c.org/TR/2004/PER-xmlschema-1-20040318/#rcase-MapAndSum

I'd like to request that rcase-MapAndSum.2 be rephrased to make it more readable. There are a number of places in the these documents that suffer the same sort of human-parseability problems but this sentence is particularly egregious.

See the original email for details on the issues and suggested wording changes: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0080.html

The attempt to make redundant derivations using repeated Exclusive facets with the same value works only part way. According to the definitions, One can derive a from decimal setting using maxExclusive = 29, redundantly derive b from a using maxExclusive = 29, but are then not permitted to derive c from b again using maxExclusive = 29. (Weird, but that's the way it is.)

This one-level redundancy is explicitly permitted by the definitions of minExclusive and maxExclusive, but didn't make its way into the descriptions of the schema components, nor of the XML representation summaries. So they contradict the definition. I suspect this is an editorial error in 2E PER.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0085.html

In certain cases, I'm not sure the current REC makes the right call on when to do recursive checking up the base type chain and when not.

Consider the following schema document:

<xs:schema>
 <xs:element name="root" type="top"/>
 
 <xs:complexType name="top" final="restriction">
  <xs:sequence>
   <xs:element name="a" minOccurs="0"/>
  </xs:sequence>
 </xs:complexType>
 
 <xs:complexType name="intermediate">
  <xs:complexContent>
   <xs:extension base="top">
    <xs:sequence>
     <xs:element name="b"/>
    </xs:sequence>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>
 
 <xs:complexType name="bottom">
  <xs:complexContent>
   <xs:restriction base="intermediate">
    <xs:sequence>
     <xs:element name="b"/>
    </xs:sequence>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>
 
 <xs:complexType name="top2">
  <xs:sequence>
   <xs:element name="c" type="top"/>
  </xs:sequence>
 </xs:complexType>
 
 <xs:complexType name="restrictOKorNot">
  <xs:complexContent>
   <xs:restriction base="top2">
    <xs:sequence>
     <xs:element name="c" type="bottom"/>
    </xs:sequence>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>
</xs:schema>

The constraints on type definitions do _not_ recurse up the chain when checking 'final', so the type def named 'bottom' above is OK, despite restricting away an element ('a') introduced in a type definition which says it's final for restriction.

However, content model checking _does_ recurse up the chain, so the type defn named 'restrictOKorNot' is _not_ OK. Neither is that following instance, wrt the schema corresponding to the above schema doc:

<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:type="bottom">
 <b/>
</root>

Is this really what we want?

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0087.html

The Rec is silent on the implications of failure of schemaLocation to resolve for redefine.

See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0088.html

Definition of {facets} in 4.1.2.1 Derivation by restriction:

{facets} The union of the set of Facets (2.4) components resolved to by the facet [children] merged with {facets} from {base type definition}, subject to the Facet Restriction Valid constraints specified in Facets (2.4).

What is being "unioned" and how does "merge" work? For example, if the base has a minLength facet with value 5 and the derived type has a minLength child facet of value 7, how many minLength facets are in the derived type's facets property?

The text above makes it sound like both are present, but constraints within the rec strongly imply there is only one facet for each facet name. (For instance, reference to "*the* minLength facet" for validation constraints). Common sense suggests the last facet of a given name wins, but it's hard to get that from "union" and "merge".

Related member-only thread: Facet equality: questions/issues http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004Mar/0187.html

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

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

How are multiple pattern facet children represented in the schema component infoset? The pattern facet schema component has a value which is a regular expression. So presumably, that value is the disjunction of all patterns among the children. Is that so? How is the disjunction written? "p1|p2|p3", for instance?

What about pattern facets at different levels in the derivation? The rec says they are effectively ANDed together, but how is that represented in the schema infoset, as there is no conjunction operator in the regex language? Is the schema processor to figure out the conjunction? Or do the base and derived patterns stay separate, with the processor required to walk the base chain for the ANDing? Or are there multiple pattern facets in the component model? I'm guessing the patterns at different derivation steps stay separate, but it's only a guess.

Relevant part of rec (part 2):

Schema Representation Constraint: Multiple patterns
If multiple <pattern> element information items appear as [children] of a <simpleType> the [value]s should be combined as if they appeared in a single regular expression as separate branches. Note: It is a consequence of the schema representation constraint Multiple patterns (4.3.4.3) and of the rules for restriction that pattern facets specified on the same step in a type derivation are ORed together, while pattern facets specified on different steps of a type derivation are ANDed together.

Related member-only thread: Facet equality: questions/issues http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004Mar/0187.html

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

In the proposed second edition of Schema Part 1, in section 3.4.2 (XML Representation of Complex Type Definitions), in the definition of the property {attribute wildcard}, there are two rules numbered 3.2.1.

The second such rule is preceded by the phrase "The value is then determined by the appropriate case among the following"; but there is only one following case. There seems to be an "otherwise" case missing.

Although the rule numbering was different in the first edition, the same problem seems to exist there.

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

PB -- RFC says application should make sure never to escape a string twice.

HT -- XLink explicitly does _not_ escape # or %. I think that was our last group consensus.

PB -- believe they should include a health warning. Will cause confusion.

HT -- that may be the right resolution. Propose -- "The question of escaping % is vexed. The issue should be explained in an accompanying note so that readers will be confident that this is an intentional omission."

XG -- sounds fine.

...

SG -- we don't have such a health warning in our spec.

HT -- I think that's OK. We need to raise an issue against 3.2.17.1.

http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004May/0047.html

The first constraint in 4.3.8.4 of the datatype spec says

"It is an error for both maxInclusive and maxExclusive to be specified in the same derivation step of a datatype definition."

And the first constraint [2] in 4.3.9.4 says

"It is an error for both minInclusive and minExclusive to be specified for the same datatype."

Clearly they don't match with each other. IMO, the one in 4.3.9.4 is incorrect, and should be changed to something similar to that in 4.3.8.4.

Discussed on 20 February 2004 and agreed to be a problem. The question arose in discussion of a draft comment on the QT serialization spec. The relevant part of our minutes reads:

HST was unhappy about the mention of QNames being type-valid when unbound; he remembered it differently. We discussed this question for a few minutes; some WG members (HST) believed having a binding for the prefix is essential to QName type validity, while some (MSM, PVB) believed they remembered removing that from the definition of type validity at the same time we removed the uniqueness constraint from the type-validity conditions for ID and moved it into Structures.

Ultimately, we constructed what amounts to an argument that having a bound prefix IS a condition of type validity. At the very least, if you have a type derived from QName via enumeration, you'll need a QName value to check instances against the enumeration. If you don't have a binding for the prefix, you won't have a value. The same goes for any other facet except 'pattern'. Therefore, a prefix binding seems essential at least for types derived from QName; as regards QName itself, some WG members suggested that the binding might not be essential; at least, they could not find any general rule that says that an instance of a simple type is type-valid if and only if the lexical form successfully maps into a type.

Other WG members noted that clause 2 of validation rule Datatype Valid (http://www.w3.org/XML/Group/2003/09/xmlschema-2/datatypes-with-errata.html#cvc-datatype-valid) requires that "the value denoted by the literal matched in the previous step [be] a member of the value space of the datatype, as determined by it being Facet Valid (sect. 4.1.4) with respect to each member of {facets} (except for pattern)." This seems to entail that there must be such a value, and thus constitute a requirement that the LV mapping must succeed for an instance to be type-valid.

Mary Holstege's note reads:

The question is whether this instance:

   <tricky qname="unbound:something"/>

would be invalid per this element declaration:

   <xs:element name="tricky">
     <xs:complexType>
       <xs:attribute name="qname" type="xs:QName"/>
     </xs:complexType>
   </xs:element>

It is valid per the lexical rules in part 2, so the only question comes as to where we make an appeal to their being a value and a value that we know.

The relevant clause in "Validation Rule: Datatype Valid" [3] is:

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

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

this being the only clause that makes any appeal to the value space.

Some read this as implicitly requiring you to have the value in hand in order to do the facet check.

I read this as saying that "Facet Valid" decides whether the value is OK. In this case, Facet Valid does not obtain, because there are no facets. (The clause "as determined by..." I take to be definitional.)

Further, even if it did obtain, the difficulty with a QName with an unbound prefix isn't that there isn't a value, it is only that you don't _know_ what it is. So I would look at this as very much analogous to undischarged component references, where it isn't that you know something is wrong, it is that you don't know what the state of affairs is. And indeed, if the instance document were a schema, and the "qname" attribute above were instead a "type" attribute, this would be an entirely consistent view to take.

Similarly, the only place in Structures that makes an appeal to the value is if there is some kind of value constraint. In this case, there is no value constraint, so again, those constraints don't apply. I don't believe there is any disagreement about the interpretation of the applicability of those clauses.

I did not find anywhere that explicitly requires that (a) there be a value and (b) you know what it is.

There is a note is 3.2.18 of Datatypes [4] that says:

NOTE: The mapping between literals in the lexical space and values in the value space of QName requires a namespace declaration to be in scope for the context in which QName is used.

Some read this as noting that you need to have an inscope namespace definition in order to have a good QName. But again, I don't read this as compelling me to know what the value happens to be, but only noting that indeed there are some cases where things get sticky if you want to get your hands on the right value in the value space.

I am not entirely sure that it is a good idea to require that there both be a value and that you know exactly what it is in the case of QName. (And I wonder about whether it would be a good one in some of those float/double edge cases, too.) I have always been uncomfortable with the pun of using the mechanism for declaring namespace for tags to provide namespace declarations for content (i.e. architecturally I would always prefer seeing explicit, distinct kinds of declarations). In the context of XQuery, for example, this gets strange, because the above instance would be valid if there were the necessary "declare namespace..." in the prolog, even though the instance in itself would be invalid per the putative XML Schema "must have a known value" rules. I find that odd.

Note that once you put a value constraint on the attribute or derive a type that adds some facets (enumerations, for example), you do run afoul of the cited clauses, among other things. On this we all agree.

So the questions are:

• (1) Do we in fact require that an instance of a simple type have a value to be valid? And if not, should we?
• (2) Do we in fact require that you know what the (or a?) value of an instance of a simple type is in order to be valid? And if not, should we?