XML Schema: Comments on Recommendation

Version $Id: xmlschema-rec-comments.html,v 1.38 2005/09/08 18:50:03 cmsmcq Exp $

Note, 8 September 2005:

This document was closed in May of 2004 and is no longer being maintained. The XML Schema Working Group is now using the public W3C instance of the Bugzilla issue-tracking system to manage comments on the XML Schema Recommendation. For current information on any of the items listed here, look for its number (e.g. "R-112") among the Bugzilla entries for XML Schema.

This document summarizes the comments on the XML Schema Recommendation. Comments received via the XML Schema Comments list, up until April 18, 2004, are recorded in this version of the document.

The process by which the XML Schema WG plans to handle these issues is described at http://www.w3.org/XML/2001/07/xmlschema-errataprocess.html.

Material reproduced from comments has been marked up, and obvious typos have been corrected. Postings and documents which raise several substantively distinct points have been silently divided among several comments. To consult the original postings, see the archive of the www-xml-schema-comments list.

Commentators are requested to review the entries for the comments they have made, and to check to make sure we have correctly understood and paraphrased their comment.

In addition to the postings to the XML Schema comments list, some postings to the XML Schema Interest-Group mailing list have been included here; this list is W3C-internal and only those with member access to the W3C web site will be able to follow the relevant hyperlinks.

Not all postings to the comments mailing list have resulted in entries in this list. For example, postings which ask for clarification and do not result in any errata, are not necessarily included in this list.

The status of each issue [at the time this document was closed] is recorded in the table. The status may be:

New
A new issue.
In progress
The WG is currently discussing the issue. The issue may or may not be classified. See the classification field for further info
Resolved
The issue has been classified and a resolution agreed upon by the WG. A note to the commentator may still be pending.
Errata Drafting
The issue has been classified and a resolution has been agreed upon by the WG. An editor or WG member is currently drafting text for the erratum.
Errata Proposed
Errata text has been drafted by an editor, and is awaiting review by the WG.
Errata Approved
Errata text has been approved by the WG, but is not yet in the Errata document
Closed
The issue is resolved, any relevant errata has been approved and added to the errata document. No further work is required for the issue

Issues have been assigned to clusters for convenience in managing discussion; cluster values preceded by '!' are highest priority, those preceded by '.' are middle priority, in the preparation of errata.

Num Cluster Part Status Classification Originator Responsible Description
R-1 . Date/Time 2 Errata drafting Error w/erratum Henry Zongaro Paul V. Biron Problem with dateTime values in 3.2.6.2
R-2 Editorial 0 Closed Editorial Dan Glickman Lisa Martin Primer states that there are 15 facets
R-3 ! Primer 0 Closed Clarification w/erratum Eddie Robertsson Priscilla Walmsley Primer states that all components must be repeated in restriction
R-4 Editorial 0 Closed Editorial Donald Gignac Lisa Martin Conflicting statements about Primer being normative/non-normative
R-5 ! Editorial 0 Closed Editorial Donald Gignac Priscilla Walmsley Typographical error in section 2.8 example
R-6 Editorial 0 Closed Editorial Donald Gignac Priscilla Walmsley Confusing table in the Primer
R-7 Unclustered (Closed) Closed Future Requirement Uwe Zeise Ashok Malhotra Request for runtime parameterization of types
R-8 ! Misc. simple types 1 Errata Drafting Error Martin Gudgin Henry S. Thompson Should finalDefault allow list, union?
R-9 Unclustered (Closed) 1 Closed Clarification w/erratum Henry Zongaro Henry S.Thompson minOccurs=0 on "all"
R-10 Editorial 2 Closed Editorial John G. de Freitas Lisa Martin Definition of bounded
R-11 Editorial 2 Closed Editorial Donald Gignac Lisa Martin Editorial error in section 4.1.2.3
R-12 Editorial 2 Closed Editorial Donald Gignac Lisa Martin Editorial error in section 4.1.2
R-13 Editorial 2 Closed Editorial Eliotte Harold Lisa Martin Typographical error in title of section 3.2.15.2
R-14 Editorial 2 Closed Editorial Panagiotis Reveliotis Lisa Martin Typographical error in section 3.2.7.1
R-15 Unclustered (Closed) 2 Closed Error Panagiotis Reveliotis Paul Biron Error in definition of ordered Schema Component
R-16 Editorial 2 Closed Editorial Eliotte Harold Lisa Martin Typographical error ("fragement") in section 3.2.17
R-17 Unclustered (Closed) 2 Closed Clarification w/erratum Martin Duerst Ashok Malhotra base64 and linebreaks every 76 characters
R-18 ! Misc. simple types 0,2 Closed Clarification/ Error Alexander Falk Priscilla Walmsley, Paul Biron Use of pattern facet for list type
R-19 Unclustered (Closed) 1 Closed Error Panagiotis Reveliotis Henry S. Thompson group element info item missing attributes
R-20 Editorial 1 Closed Editorial Panagiotis Reveliotis Lisa Martin Typographical error in section 3.4.2 example
R-21 Unclustered (Closed) 2 Closed Clarification w/Erratum Panagiotis Reveliotis Paul Biron Clarification required re: list itemType
R-22 ! Numeric Types 2 Closed Error Ashok Malhotra Ashok Malhotra/Paul V. Biron Floating Point Issues and IEEE
R-23 Unclustered (Closed) 1 Closed Clarification Mark Huffman Lisa Martin Restrictions of attributes specifying "use"
R-24 Unclustered (Closed) 1 Closed Future requirement Yan Leshinsky Henry S. Thompson Derivation by Restriction: pointless occurrences
R-25 . Misc. Structures 1 Errata Drafting Error w/erratum Satoshi Nakamura Henry S. Thompson Element locally valid: fixed value constraints
R-26 ! Editorial 1 Closed Editorial C. M. Sperberg-McQueen Henry S. Thompson Two typos in section 3.3.5 of Structures
R-27 Unclustered (Closed) 0 Closed Doc Suggestion Doug Bunting Lisa Martin Request for additional information in the Primer
R-28 ! Misc. Structures 1 Closed Error Satoshi Nakamura Henry S. Thompson Element locally valid (type): rule about "abstract"
R-29 ! Editorial 2 Closed Editorial Martin Duerst Paul V. Biron Remove request for comments from Datatypes
R-30 ! Misc. simple types 2 Closed Error Martin Duerst Paul V. Biron Request for clarification of regex notation
R-31 ! Misc. simple types 2 Closed Clarification w/Erratum James Clark Paul V. Biron anyURI and xml:base
R-32 . Cross-part 1 Closed Unclassified Jeff Rafter Unassigned Type of public attribute of notation
R-33 ! Identity Constraints 0,1 Closed Clarification/Error Neil Graham Priscilla Walmsley, Henry S. Thompson Request for clarification of identity constraint rules
R-34 ! Final and block 1 Closed Error Choi Jongwon Henry S. Thompson Potential problem with description of final for simpleType in Structures
R-35 Unclustered (Closed) 2 Closed Error Satoshi Nakamura Alexander Falk Regular expression grammar for charClass is ambiguous
R-36 ! Editorial 0 Closed Editorial Jason Stallion Priscilla Walmsley Font of text in section 2.5.2 of Primer incorrect
R-37 Editorial 2 Closed Editorial Tony Coates Lisa Martin The link to ISO 8601 in the Datatypes spec doesn't work
R-38 Numeric Types 2 Closed Clarification w/Erratum Kevin Yancey Paul V. Biron Missing constraint for fractionDigits?
R-39 Unclustered (Closed) 1 Closed Error Paul V. Biron Henry S. Thompson Error in the DTD for Schemas in Structures spec
R-40 ! Misc. simple types 2 Closed Clarification w/Erratum Paul V. Biron Paul V. Biron Clarification of the regex language in Datatypes
R-41 Misc. simple types 2 Errata Proposed Error Paul V. Biron Paul V. Biron Error in production 10 of regex in Datatypes
R-42 Unclustered (Closed) 1 Closed Future Requirement Achille Fokoue Henry S. Thompson Potential problem with particle derivation Choice:Choice rules
R-43 Primer 0 Closed Unclassified Donald Gignac Priscilla Walmsley Imprecise text in Table 1 of Primer
R-44 ! Editorial 0 Closed Editorial Donald Gignac Priscilla Walmsley Grammatical errors in section 5.6 of the Primer
R-45 ! Editorial 0 Closed Editorial Donald Gignac Priscilla Walmsley Inaccurate language in section 5.5 of Primer re: references to HTML
R-46 . Identity Constraints 1 Closed Error, Future Requirement Mary Holstege Henry S. Thompson Minor inconsistency in definition of Identity Constraints
R-47 !Type deriv. rules and groups 1 Closed Clarification w/erratum Henry Zongaro Henry S. Thompson Request for clarification of complex type derivation restriction rules for empty base
R-48 Date/Time 0,2 Closed Error Henry Zongaro Priscilla Walmsley, Ashok Malhotra/Paul V. Biron Lexical representation of gMonth is inconsistent wrt ISO 8601
R-49 Date/Time 2 In progress Unclassified Henry Zongaro Unassigned ISO 8601:2000 defines 0000 as a valid year
R-50 ! Primer 0 Closed Error Scott Means Priscilla Walmsley "appInfo" element in Primer vs. "appinfo" element in Structures
R-51 Primer 0 Closed Clarification Mark Hurley Unassigned Inaccurate text in section 2.3 of the Primer
R-52 ! Type deriv. rules and groups 1 Closed Error Sandy Gao Henry S. Thompson Missing constraint for indirect circular attribute group?
R-53 Type deriv. rules and groups 1 Closed Clarification Sandy Gao Henry S. Thompson Request for clarification of include
R-54 ! Type deriv. rules and groups 1 Closed Clarification w/erratum Sandy Gao Henry S. Thompson Request for clarification of ur-type
R-55 Editorial 0 Closed Editorial Bill Thompson Priscilla Walmsley Typo in table 2 of the Primer
R-56 ! Editorial 2 Errata Drafting Editorial Donald Gignac Paul V. Biron Grammatical error in section 2.5.2 of Datatypes spec
R-57 Editorial 1 Closed Editorial Donald Gignac Henry S. Thompson Inconsistent capitalization in section 2.1 of Structures
R-58 . Primer 0 Closed Editorial Donald Gignac Priscilla Walmsley Errors in example in Appendix C of Primer
R-59 Primer 0 Closed Unclassified Donald Gignac Priscilla Walmsley Suggested changes for Appendix C of Primer
R-60 ! Type deriv. rules and groups 1 Closed Error Henry S. Thompson Henry S. Thompson Problem with particle derivation rules and the Schema for Schemas
R-61 ! Editorial 2 Closed Error Thomas Broyer Paul V. Biron Typo in section D.3.1 "Sign Allowed" of Datatypes spec
R-62 Identity Constraints 1 Closed Error Henry S. Thompson Henry S. Thompson Whitespace and identity constraint XPath expressions
R-63 Unclustered 2 Closed Clarification w/erratum Donald Gignac Paul V. Biron Suggested change for union example in section 2.5.1.3 of Datatypes spec
R-64 Misc. Structures 1 Closed Error Asir Vedamuthu Henry S. Thompson Issue with complex type property mapping rules for content type
R-65 ! Wildcards 1 Closed Error Sandy Gao Henry S. Thompson Issues with the rules for wildcard union, subset, and intersection
R-66 ! Misc. simple types 1,2 Closed Error Asir Vedamuthu Paul V. Biron, Henry S. Thompson Magic built-in datatypes: ENTITY and ENTITIES
R-67 ! Type deriv. rules and groups 0,1 Closed Clarification w/erratum, Future Requirement Lisa Martin Priscilla Walmsley, Henry S. Thompson A question about type derivation and anonymous types
R-68 ! Type deriv. rules and groups 1 Closed Error Alexander Falk Henry S. Thompson Contradiction in Structures re: base for complexTypes with simpleContent
R-69 Misc. simple types 0,2 Closed Error Alexander Falk Priscilla Walmsley, Paul V. Biron Problem in the regex grammar for charRange
R-70 ! Editorial 2 Closed Editorial Eric van der Vlist Henry S. Thompson Typo in the Schema for Schemas
R-71 ! Editorial 1 Closed Editorial Henry S. Thompson Henry S. Thompson Editorial error in the text for Element Declarations Consistent
R-72 ! Editorial 1 Errata Drafting Editorial Elliotte Rusty Harold Henry S. Thompson Typo in appendix E of Structures
R-73 . Misc. Structures 1 Errata Drafting Clarification w/erratum Lisa Martin Henry S. Thompson Question about unions of attribute uses
R-74 ! Type deriv. rules and groups 1 Closed Error Henry S. Thompson Henry S. Thompson Missing constraint for circular substitution groups?
R-75 Misc. simple types 2 Closed Error Eric van der Vlist Paul V. Biron Potential problem with the rules for maxExclusive
R-76 Unclustered (Closed) 1 Closed Clarification Lisa Martin Lisa Martin Question about content type EMPTY
R-77 Identity Constraints 1 Errata Drafting Clarification w/erratum, Future Requirement Jeni Tennison Henry S. Thompson Issue to do with identity constraints and chameleon include
R-78 ! UPA and content models 1 Closed Error Sandy Gao Henry S. Thompson Issue to do with definition of substitution groups, block, and UPA
R-79 . Type deriv. rules and groups 1 Errata Drafting Error Sandy Gao Henry S. Thompson Ambiguity in statements about valid type derivation
R-80 . Wildcards 0,1 Closed Error Amy Moulton Priscilla Walmsley, Henry S. Thompson Meaning of ##other
R-81 ! Identity Constraints 0 Closed Error Priscilla Walmsley Priscilla Walmsley Error in Primer example of identity constraints
R-82 . Primer 0 Closed Unclassified Priscilla Walmsley Priscilla Walmsley Three editorial errors in the Primer
R-83 Misc. simple types 2 Closed Error Henry S. Thompson Paul V. Biron/Ashok Malhotra Token should exclude #xD from lexical and value spaces
R-84 . Final and block 1 Errata Drafting Clarification w/erratum Priscilla Walmsley Henry S. Thompson Can final="extension" for simpleType?
R-85 QNames 2 Errata Drafting Clarification w/erratum Eric Van der VList Henry S. Thompson Request for clarification of QName type
R-86 UPA and content models 1 Closed Clarification w/erratum Sandy Gao Henry S. Thompson Request for clarification of UPA
R-87 ! Misc. Structures 1 Closed Error Stanley Guan Henry S. Thompson Error in section 3.4.2 of Structures
R-88 ! Misc. simple types 2 Closed Clarification w/erratum Eric van der Vlist Ashok Malhotra, Paul V. Biron Suggested changes to clarify NOTATION
R-89 ! Misc. simple types 2 Closed Error Henry Zongaro Paul V. Biron, Ashok Malhotra Is a trailing decimal point permitted for integer?
R-90 ! Date/Time 2 Errata Drafting Error Henry Zongaro Ashok Malhotra/Paul V. Biron Questions about the lexical and canonical rep'ns of dateTime
R-91 Named Groups 1 New Unclassified Henry S. Thompson Unassigned Optional self-reference in group redefinition
R-92 Named Groups 1 New Unclassified Henry S. Thompson Unassigned Clarification required for group redefinition
R-93 Wildcards 1 Closed Error w/erratum Kohsuke Kawaguchi Henry S. Thompson Problem with derivation by restriction and anyAttribute
R-94 Identity Constraints 1 Errata Drafting Clarification w/erratum, Future requirement Khaled Noaman/Henry S. Thompson Henry S. Thompson Issues with identity constraints and derivation by restriction
R-95 Unclustered (Closed) 0 Closed Doc Suggestion Kenneth Geisshert Unassigned Request for PDF version of the Primer
R-96 Misc. Structures 1 Errata Drafting Error Henry S. Thompson Henry S. Thompson Problem with scope property of attributes
R-97 ! Misc. simple types 2 Closed Error Ashok Malhotra Paul V. Biron, Ashok Malhotra Problem with canonical rep'n of float/double
R-98 . Qnames 2 In progress Error Sandy Gao Paul V. Biron/Ashok Malhotra Question about the canonical rep'n of QName
R-99 ! Misc. simple types 2 Closed Error Sandy Gao Paul.V.Biron Issue re: the length facet for NMTOKENS, IDREFS, ENTITIES
R-100 ! UPA and content models 1 Closed Error Sandy Gao Henry S. Thompson Issue re: description of overlapping for UPA, Appendix H
R-101 ! UPA and content models 1 Closed Clarification w/erratum Sandy Gao Henry S. Thompson Issue re: UPA and groups
R-102 ! Type deriv. rules and groups 1,2 Closed Error Henry S. Thompson Henry S. Thompson, Paul V. Biron/Ashok Malhotra Errata in restriction constraints wrt simple type defns?
R-103 ! Editorial 1 Closed Editorial Ross Thompson Henry S. Thompson The term PSVI needs to be defined
R-104 ! Primer 0 Closed Clarification w/erratum Rieks van der Straaten Priscilla Walmsley Primer question re: integer and the fractionDigits facet
R-105 . Identity Constraints 1 Closed Future Requirement Henry S. Thompson Unassigned Comment re: identity constraints property in Schema component
R-106 ! QNames 2 Closed Clarification w/Erratum Anli Shundi Paul V. Biron, Ashok Malhotra Clarification requested re: facets for QName type
R-107 ! Misc. Structures 1 Closed Error Henry S. Thompson Henry S. Thompson Change required re: note in section 4.2.1 of Structures
R-108 Numeric Types 2 In progress Unclassified Michael Sperberg-McQueen Unassigned Clarification requested re: rounding of floats
R-109 ! Cross-part 1 Closed Error Martin Gudgin Henry S. Thompson Mismatch between Parts 1 and 2 in the area of facet constraints
R-110 ! Numeric Types 2 Closed Error Sandy Gao Paul V. Biron, Ashok Malhotra Error in example in section 4.3.11 of Datatypes?
R-111 Wildcards 1 New Unclassified Eric van der Vlist Unassigned Why are foreign attributes not permitted for appinfo and documentation?
R-112 . Misc. Structures 1 In progress Error w/erratum Sandy Gao Unassigned A question about QName Resolution (Schema Document)
R-113 ! UPA and content models 1 Closed Clarification w/erratum Lisa Martin Henry S. Thompson A question about all content models
R-114 QNames 1 In progress Unclassified Jonathan Marsh Unassigned Schema infoset fix-ups
R-115 . QNames 1,2 In progress Unclassified Ashok Malhotra Unassigned Validating attributes with default value of type QName
R-116 . Cross-part 2 Closed Error w/erratum Ross Thompson Paul V. Biron Question about the type of a pattern value
R-117 ! Misc. Structures 1 Closed Error w/erratum Henry S. Thompson Henry S. Thompson Problem with processContents for the ur-type
R-118 . Date/Time 2 Closed Error w/erratum Michael Kay Unassigned Questions about the value space for dateTime
R-119 ! Date/Time 2 Closed Clarification w/erratum Michael Kay Paul V. Biron, Ashok Malhotra Question about the value space for date
R-120 ! Date/Time 2 Closed Error Michael Kay Paul V. Biron, Ashok Malhotra Question about the canonical representation of date
R-121 ! Primer 0 Closed Error Jeffrey Stephenson/Henry S. Thompson Priscilla Walmsley Import example in section 5.4 of Primer incorrect
R-122 . Type deriv. rules and groups 1 Errata Drafting Error Eric van der Vlist Henry S. Thompson Issue re: restricting substitution groups
R-123 . Misc. Structures 1 Closed Clarification without erratum Mark Feblowitz Unassigned A question about redefining redefines
R-124 PSVI 1 Errata Drafting Editorial/Future Requirement Lisa Martin Henry S. Thompson A question about PSVI properties
R-125 ! Editorial 1 Closed Editorial Wojtek Murawski Henry S. Thompson Editorial error in section 4.3.2 of Structures
R-126 Primer 0 Closed Unclassified Simon Cox Priscilla Walmsley Suggested change for the Primer re: substitution group members
R-127 . Date/Time 2 Errata Drafting Clarification w/erratum Henry Zongaro Ashok Malhotra Distinction between 00:00:00 and 24:00:00 for time datatype?
R-110b !Numeric Types 2 Closed Error Henry Zongaro Paul V. Biron Does the fractionDigits facet apply to the value space or lexical space?
R-128 Misc. simple types 2 Errata Drafting Clarification w/erratum C.M. Sperberg-McQueen Dave Peterson Question re: leading zeros for gYearMonth and gMonth
R-129 ! Misc. Structures 1 Closed Error Henry S. Thompson Henry S. Thompson type of id attr on schema elt
R-130 ! Misc. simple types 2 Closed Error Lin Yeng Husband Paul V. Biron, Ashok Malhotra Pattern of language type in XMLSchema.xsd
R-131 ! Editorial 2 Closed Editorial Richard Emberson Paul V. Biron Typo in description of duration in datatypes
R-132 . Misc. simple types 2 Errata Drafting Error w/erratum Paul V. Biron Ashok Malhotra Equiv comparisons on anyURI
R-133 . Misc. Structures 1 Errata Drafting Error w/erratum Daniel Veillard Henry S. Thompson Regex for XPath in S4S invalid
R-134 . Misc. simple types 2 In progress Error w/erratum James Clark Paul V. Biron Treatment of ^ in regexes
R-135 ! Misc. simple types 2 Closed Error James Clark Paul V. Biron, Ashok Malhotra Question about surrogate characters in F.1.1
R-136 ! Unclustered 1 Closed Error Rahul Srivastava Henry S. Thompson Question about selector XPath expressions
R-137 ! Unclustered 1 Closed Error Jerome Simeon Henry S. Thompson Can substitution groups contain local elements?
R-138 ! Unclustered 1 Closed Clarification w/erratum Aung Aung Henry S. Thompson The S4S contains derivations with anySimpleType as the base
R-139 ! Unclustered 2 Closed Error James Clark Paul V. Biron, Ashok Malhotra Appendix D of datatypes does not permit 24:00 for date/time types
R-140 . Unclustered 2 In progress Error w/erratum James Clark Unassigned dateTime order relation and leap seconds
R-141 . Unclustered 2 In progress Error w/erratum James Clark Unassigned Changes suggested re: dateTime order relation
R-142 ! Unclustered 2 Closed Error w/erratum James Clark Ashok Malhotra, Paul V. Biron Order relation for gMonthDay, gMonth, gDay
R-143 ! Unclustered 1 Closed Error Henry S. Thompson Henry S. Thompson Subtle bug in schema doc. for schemas
R-144 . Unclustered 2 Errata Drafting Error w/erratum James Clark Ashok Malhotra Adding durations to dateTime
R-145 . Unclustered 2 Errata Drafting Error w/erratum James Clark Ashok Malhotra Leap second validation
R-146 . Unclustered 2 Closed Clarification James Clark Ashok Malhotra Double leap seconds
R-147 ! Unclustered 2 Closed Error James Clark Ashok Malhotra, Paul V. Biron Lexical form of duration components
R-148 . Unclustered 2 In progress Unclassified James Clark Asir Vedamuthu Trailing decimal point in seconds field of dateTime and time
R-149 ! Unclustered 2 Closed Clarification w/erratum James Clark Ashok Malhotra, Paul V. Biron Is +0 allowed as a nonPositiveInteger in lexical form?
R-150 ! Unclustered 2 Closed Clarification w/erratum Sandy Gao Ashok Malhotra Are international digit characters allowed for date/time types?
R-151 ! Unclustered 2 Closed Clarification w/erratum Sandy Gao Ashok Malhotra Questions about equal fundamental facet
R-152 ! Unclustered 2 Closed Error James Clark Unassigned When is T designator required with duration?
R-153 !Unclustered 1 Closed Error Walter Waterfeld Henry S. Thompson Is the public attribute of notation optional?
R-154 .Unclustered 1 Errata Drafting Editorial Andrew Watt Henry S. Thompson Typo in section 5.1 of Structures?
R-155 .Unclustered 0 Closed Editorial Priscilla Walmsley Unassigned 4 Typos in the Primer
R-156 !Unclustered 1 Closed Clarification w/Erratum Asir Vedamuthu Henry S. Thompson Question about mixed="true" and simpleContent
R-157 !Unclustered 1 Closed Clarification without erratum Ashok Malhotra Unassigned Question about non-deterministic content models
R-158 .Unclustered 1 Closed Future Requirement Asir Vedamuthu Unassigned topLevelAttribute and use=(optional|prohibited|required)
R-159 !Unclustered 1 Closed Error Henry S. Thompson Henry S. Thompson Bug in the spec wrt attribute defaults
R-160 !Unclustered 1 Closed Clarification without erratum Dave Hollander Paul V. Biron Question re: validity of type override with union type
R-161 !Unclustered 1 Closed Error James Clark Henry S. Thompson QName resolution to components with no target namespace
R-162 !Unclustered 1 Closed Error w/erratum John Verhaeg Henry S. Thompson Errors in section 3.14.6 of Structures
R-163 .Unclustered 1 Errata Drafting Clarification w/erratum; Future Requirement David Stephenson Henry S. Thompson Inconsistency between S4S and schema component information re: annotations
R-164 .Unclustered 0 Closed Doc Suggestion Ben Clemens Priscilla Walmsley Suggestion for change to Primer PO Example
R-165 .Unclustered 1 Errata Drafting Clarification w/erratum James Clark Henry S. Thompson Clarification requested for statement in Appendix H of Structures
R-166 .Unclustered 1 Closed Error w/eratum Richard Tobin Henry S. Thompson Question re: xsi:type and skip
R-167 !Unclustered 1 Closed Clarification without erratum/Future Requirement Richard Tobin Unassigned Question about assessment outcome for attributes
R-168 .Unclustered 1 Closed Clarification Richard Tobin Sandy Gao Question about error codes
R-169 !Unclustered 1 Closed Error w/erratum Paul V. Biron Henry S. Thompson Type of the public identifier of notations
R-170 !Unclustered 1,2 Closed Future Requirement Berthold Daum Unassigned Inconsistent use of the term "derived"
R-171 !Unclustered 1 Errata Drafting Error w/erratum Richard Tobin Henry S. Thompson Question about fixed value constraint on element
R-172 .Unclustered 1 Errata Drafting Clarification w/erratum; Future Requirement Neil Graham Henry S. Thompson Questions viz. when fields match element with the ur-type
R-173 !Unclustered 2 Closed Clarification without erratum John Mercado Ashok Malhotra Canonical form of duration
R-174 .Unclustered 1 Closed Future Requirement Elena Litani Unassigned Question re: PSVI document property
R-175 !Unclustered 2 Errata Approved Error w/erratum Michael Kay Ashok Malhotra Questions re: normalizedString
R-176 .Unclustered 1 In progress Unclassified Masayasu Ishikawa Unassigned Question about mixed in derivation by extension
R-177 .Unclustered 2 Errata Proposed Clarification w/erratum Ashok Malholtra Ashok Malhotra Should list of IDs be allowed?
R-178 Unclustered 1 New Unclassified Stanley Guan,Ashok Malholtra Unassigned Question about use and fixed for attributes
R-179 . Unclustered 2 Errata Drafting Error w/erratum Asir Vedamuthu Ashok Malhotra Defect in schema component model wrt enumeration and annotations
R-180 Unclustered 1 New Unclassified Sandy Gao Unassigned Question about the schema error code property in the PSVI
R-181 . Unclustered 1,2 Errata Drafting Error w/erratum Stefan Wachter Ashok Malhotra Question about equality of lists
R-182 . Unclustered 1,2 New Unclassified Stefan Wachter Unassigned Question about equality and union types
R-183 . Unclustered 1 New Unclassified Sandy Gao Unassigned Question about default values
R-184 . Unclustered 2 New Unclassified Henry S. Thompson Unassigned Question about pattern and union types
R-185 Unclustered 2 Errata Drafting Error w/erratum Jeremy Carroll Unassigned Question about cardinality of calendar types
R-186 . Unclustered 2 In progress Unclassified Sandy Gao Unassigned Constraints for min/maxIn/Exclusive facets
R-187 . Unclustered 1,2 New Unclassified Sandy Gao Unassigned Missing constraints
R-188 Unclustered 0 New Unclassified Arthur E. Salwin Unassigned Potential errors in the Primer
R-189 ! Unclustered 1 Errata Drafting Error Herve Verjus Henry S. Thompson Recursive simple type definitions
R-190 Unclustered 2 Closed Future Requirement Steven Taschuk Ashok Malhotra Truncation is not defined
R-191 ! Unclustered 1 Errata Drafting Error Sandy Gao Henry S. Thompson Question about e-props-correct.2
R-192 . Unclustered 2 Errata Proposed Error w/erratum Steven Taschuk Ashok Malhotra Revisiting issue about canonical form for duration
R-193 ! Unclustered 1 Errata Drafting Error w/erratum Lisa Martin Henry S. Thompson Question re: processContents=skip
R-194 ! Unclustered 1 Errata Drafting Clarification w/erratum Lisa Martin Unassigned Question re: processContents=skip
R-195 . Unclustered 2 In progress Error w/erratum Dave Peterson Unassigned Correct error in the description of order for dateTime
R-196 . Datatypes (General) 2 Errata approved Clarification w/erratum Francois Yergeau Ashok Malhotra Add health warning on use of whitespace facet on elements
R-197 Datatypes (General) 2 In progress Clarification w/erratum Noah Mendelsohn Unassigned Add warning on whitespace processing
R-198 ! Datatypes (General) 2 Closed Error, Defer to 1.1 Ed Merks Unassigned Problem with unions of unions
R-199 ! Datatypes (General) 2 Errata Drafting Error w/erratum Lisa Martin/Ed Merks Paul Biron, Henry Thompson Problem with final for simple types
R-200 ! Unclustered 1 Errata Drafting Error w/erratum Sandy Gao Henry Thompson Problem with erratum E1-18
R-201 ! Datatypes (General) 2 Closed Editorial Paul Biron Paul Biron The link to IETF INTERNET-DRAFT: IRIs in the Datatypes spec is wrong
R-202 Unclustered 1 New Unclassified Schema WG Unassigned How many components are there for complextype extensions?
R-203 Unclustered 2 New Unclassified Sandy Gao Unassigned Inconsistency with constraints on min/maxExclusive
R-204 Unclustered 1 New Unclassified Sandy Gao Unassigned ComplexType mapping rule issue: min=max=0
R-205 Unclustered 1 New Unclassified Sandy Gao Unassigned Question re: mixed on complexType and complexContent
R-206 Unclustered 1 Errata Drafting Clarification w/erratum Rainer Becker (via Henry S. Thompson) Henry S. Thompson Can fields identity nodes with types having simpleContent?
R-207 Unclustered 1 New Unclassified Dare Obasanjo Unassigned Question about wildcard restriction
R-208 Unclustered 2 New Unclassified Sandy Gao Unassigned Question about the lexical space of NOTATION types
R-209 Unclustered 1 New Unclassified Dmitry Trifonov Unassigned appinfo and documentation elements have no id attribute
R-210 Unclustered 0 New Unclassified Emmanuel Languillat Unassigned Ambiguity in the Primer
R-211 Unclustered 1 New Unclassified C.M. Sperberg-McQueen Unassigned The {attributes} property on the Annotation schema component
R-212 Unclustered 1 New Unclassified C.M. Sperberg-McQueen Unassigned Question about VR Element Locally Valid (Element) in Structures 3.3.4
R-213 Unclustered 1 New Unclassified Xan Gregg Unassigned Question about attribute wildcards and restriction
R-214 Unclustered 2 Errata Drafting Error w/erratum Sandy Gao Ashok Malhotra Question about the value space of double
R-215 Unclustered 1 Errata Drafting Error w/erratum Tim Hanson Henry S. Thompson Whitespace and identity constraints
R-216 Unclustered 1 New Unclassified Sandy Gao Unassigned Potential problem with Name and Type OK
R-217 Unclustered 1 New Unclassified Sandy Gao Unassigned Potential problem with Derivation Valid (Restriction, Complex)
R-218 Unclustered 1 Errata Approved Error w/ erratum Sandy Gao Henry S. Thompson Clarification required for complexContent extending simpleContent
R-219 Unclustered 1 New Unclassified Schema WG Unassigned Does section 3.11.1 of part 1 need to refer to list, union?
R-220 Unclustered 1 New Unclassified Henry S. Thompson Unassigned Problem with erratum E1-17
R-221 Unclustered 2 In progress Clarification w/erratum John Tebbutt Unassigned Question about decimal values with >18 digits
R-222 Unclustered 2 New Unclassified Schema WG Unassigned Should XML Schema continue to define the XMLSchema-datatypes namespace?
R-223 Unclustered 1 New Unclassified D. Schenk Unassigned Suggested change to an example in Structures
R-224 Unclustered 2 New Unclassified Michael Sperberg McQueen Unassigned Questions about metacharacters in regular expressions
R-225 Unclustered 1 New Unclassified Sandy Gao Unassigned Question about fixed element value with simple type
R-226 Unclustered 1 New Unclassified Henry S. Thompson Unassigned Must the content of schemaLocation be a resolvable URL?
R-227 Unclustered 1 New Unclassified Tim Hanson Unassigned identity constraints and xsi:nil
R-228 Unclustered 2 New Unclassified Anli Shundi Unassigned Suggestion for changes in fractionDigits example in part 2
R-229 Unclustered 2 New Unclassified Steve Hanna Unassigned Order relation on time
R-230 Unclustered 1 New Unclassified Tim Daplyn Unassigned Question on maxOccurs=0, particles and restriction
R-231 Unclustered 1,2 New Unclassified Henry S. Thompson Unassigned Enumeration restrictions are unclear
R-232 Unclustered 1 New Unclassified Michael Sperberg-McQueen Unassigned Vacuous Redefinition
R-233 Unclustered 1 New Unclassified Henry S. Thompson Unassigned Validation of xsi: attributes
R-234 Unclustered 1 New Unclassified Kazumi Saito Unassigned Anonymous global type elements of same name in model group
R-235 Unclustered 2 New Unclassified Arjohn Kampman Unassigned Canonical rep'n of -0.0
R-236 Unclustered 2 New Unclassified Dan Connolly Unassigned whitespace facet constrains value space of integer?
R-237 Unclustered 1 New Unclassified David Bau Unassigned Possible errors in the S4S
R-238 Unclustered 0 New Unclassified David Bau Unassigned Primer Section 2.3 - Empty Content
R-239 Unclustered 1 New Unclassified David Bau Unassigned Question re: Element Declarations Consistent
R-240 Unclustered 1 New Unclassified Alessandro Triglia Unassigned Question re: Particle Derivation OK (All/Choice/Sequence:Any -- NSRecurseCheckCardinality)
R-241 Unclustered 1 New Unclassified Michael Marchegay Unassigned Question re: Validation of an element restriction whose base type has the variety union
R-242 Unclustered 1 New Unclassified Michael Kay Unassigned Part 1: final attribute of simpleType
R-243 Unclustered 1 New Unclassified Henry S. Thompson Unassigned Can an attribute prohibited by restriction be added back through a subsequent extension?
R-244 Unclustered 2 New Unclassified Joseph Fialli Unassigned Clarification requested for Appendix E
R-245 Unclustered 1 New Unclassified Dan Small Unassigned Editorial error in section 3.1.4 of Structures
R-246 Unclustered 2 New Unclassified Walter Waterfeld Unassigned IDREFS and space
R-247 Unclustered 2 New Unclassified Walter Waterfeld Unassigned 2E PER: bracket missing in pattern for lexical space of xs:language
R-248 Unclustered 2 New Unclassified Anli Shundi Unassigned 2E PER: Typos in 2E Datatypes spec
R-249 Unclustered 2 New Unclassified Bob Foster Unassigned 2E PER: Objection to erratum E2-18
R-250 Unclustered 1 New Unclassified Eric J. Schwarzenbach Unassigned 2E PER: Comments on rcase-MapAndSum
R-251 Unclustered 2 New Unclassified Dave Peterson Unassigned 2E PER: Probable editorial problem, mix/maxExclusive facets
R-252 Unclustered 1 New Unclassified Henry S. Thompson Unassigned Final/block, transitivity and restriction
R-253 Unclustered 1 New Unclassified Henry S. Thompson, Noah Mendelsohn Unassigned Failure of schemaLocation to resolve for redefine
R-254 Unclustered 2 New Unclassified Xan Gregg Unassigned Clarify merge/union of facets
R-255 Unclustered 2 New Unclassified Xan Gregg Unassigned Value of pattern facet
R-256 Unclustered 1 New Unclassified Michael Kay Unassigned 2E PER: Attribute wildcards numbering problem
R-257 Unclustered 2 New Unclassified XML Schema WG Health warning needed about percent-escaping URIs
R-258 Unclustered 2 New Unclassified Sandy Gao Need to resolve contradiction regarding inclusive and exclusive bounds
R-259 Unclustered 2 New Unclassified Mary Holstege and XML Schema WG Are QNames without prefix bindings type-valid?

R-1. pfiComparingDurations: Problem with dateTime values in 3.2.6.2

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: Errata drafting
Originator: Henry Zongaro

Description

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.

Resolution

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)



R-2. pfiPrimerNumFacets: Primer states that there are 15 facets

Classification: Editorial
Part: 0 (Primer)
Status: Closed
Originator: Dan Glickman

Description

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.

Resolution

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

Erratum number is: E0-1.



R-3. pfiPrimerRestriction: Primer states that all components must be repeated in restriction

Classification: Clarification w/erratum
Part: 0 (Primer)
Status: Closed
Originator: Eddie Robertsson

Description

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.

Resolution

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

Erratum E0-21 added.



R-4. pfiPrimerNormative: Conflicting statements about Primer being normative/non-normative

Classification: Editorial
Part: 0 (Primer)
Status: Closed
Originator: Donald Gignac

Description

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.

Resolution

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.



R-5. pfiPrimerTypo2.8: Typographical error in section 2.8 example

Classification: Editorial
Part: 0 (Primer)
Status: Closed
Originator: Donald Gignac

Description

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.

Resolution

An erratum will be added as proposed above.

Erratum E0-19 added.



R-6. pfiPrimerTable4.4: Confusing table in the Primer

Classification: Editorial
Part: 0 (Primer)
Status: Closed
Originator: Donald Gignac

Description

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.

Discussion

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

Resolution

Erratum E0-20 added.



R-7. pfiRuntimeTypes: Request for runtime parameterization of types

Classification: Future Requirement
Part:
Status: Closed
Originator: Uwe Zeise

Description

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

Resolution

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



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

Classification: Error
Part: 1 (Structures)
Status: Errata Drafting
Originator: Martin Gudgin

Description

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

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

Discussion

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

Resolution

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



R-9. pfiallGroup: minOccurs=0 on "all"

Classification: Clarification w/erratum
Part: 1 (Structures)
Status: Closed
Originator: Henry Zongaro

Description

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.

Resolution

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.



R-10. pfiBounded: Definition of bounded

Classification: Editorial
Part: 2 (Datatypes)
Status: Closed
Originator: John G. de Freitas

Description

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

Resolution

An erratum will be added that reflects the proposed change.

Erratum number is: E2-3.



R-11. pfiUnionTypo: Editorial error in section 4.1.2.3

Classification: Editorial
Part: 2 (Datatypes)
Status: Closed
Originator: Donald Gignac

Description

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

Resolution

An erratum will be added that corrects the grammatical error.

Erratum number is: E2-1.



R-12. pfifinalTypo: Editorial error in section 4.1.2

Classification: Editorial
Part: 2 (Datatypes)
Status: Closed
Originator: Donald Gignac

Description

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

Resolution

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.



R-13. pfihexBinaryTypo: Typographical error in title of section 3.2.15.2

Classification: Editorial
Part: 2 (Datatypes)
Status: Closed
Originator: Eliotte Harold

Description

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

The title is "Canonical Rrepresentation".

Resolution

The spelling mistake will be corrected in an erratum.

Erratum number is: E2-2.



R-14. pfidateTimeTypo: Typographical error in section 3.2.7.1

Classification: Editorial
Part: 2 (Datatypes)
Status: Closed
Originator: Panagiotis Reveliotis

Description

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

Resolution

An erratum will be added which corrects this typographical error.

Erratum number is: E2-5.



R-15. pfiordered: Error in definition of ordered Schema Component

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: Panagiotis Reveliotis

Description

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

Resolution

An erratum will be added to correct this text.



R-16. pfianyURITypo: Typographical error ("fragement") in section 3.2.17

Classification: Editorial
Part: 2 (Datatypes)
Status: Closed
Originator: Eliotte Harold

Description

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

"fragement" should be "fragment".

Erratum number is: E2-6.

Resolution

An erratum will be added correctly this spelling mistake.



R-17. pfibase64: base64 and linebreaks every 76 characters

Classification: Clarification w/erratum
Part: 2 (Datatypes)
Status: Closed
Originator: Martin Duerst

Description

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

Resolution

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.



R-18. pfipattern: Use of pattern facet for list type

Classification: Clarification/ Error
Part: 0,2 (Primer, Datatypes)
Status: Closed
Originator: Alexander Falk

Description

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.

Resolution

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.



R-19. pfigroup: group element info item missing attributes

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Panagiotis Reveliotis

Description

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

Resolution

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



R-20. pfitypeExampleTypo: Typographical error in section 3.4.2 example

Classification: Editorial
Part: 1 (Structures)
Status: Closed
Originator: Panagiotis Reveliotis

Description

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

Resolution

An erratum will be added to correct this.



R-21. pfiListitemType: Clarification required re: list itemType

Classification: Clarification w/Erratum
Part: 2 (Datatypes)
Status: Closed
Originator: Panagiotis Reveliotis

Description

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.

Resolution

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



R-22. pfiFloat: Floating Point Issues and IEEE

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: Ashok Malhotra

Description

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

Discussion

A straw poll was held for the following questions:

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

Resolution

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.



R-23. pfiattrRestrict: Restrictions of attributes specifying "use"

Classification: Clarification
Part: 1 (Structures)
Status: Closed
Originator: Mark Huffman

Description

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

Resolution

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.



R-24. pfipointless: Derivation by Restriction: pointless occurrences

Classification: Future requirement
Part: 1 (Structures)
Status: Closed
Originator: Yan Leshinsky

Description

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

Discussion

The WG has discussed various solutions:

Resolution

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.



R-25. pfifixedValidity: Element locally valid: fixed value constraints

Classification: Error w/erratum
Part: 1 (Structures)
Status: Errata Drafting
Originator: Satoshi Nakamura

Description

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

Resolution

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"



R-26. pfiPSVITypos: Two typos in section 3.3.5 of Structures

Classification: Editorial
Part: 1 (Structures)
Status: Closed
Originator: C. M. Sperberg-McQueen

Description

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

Resolution

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



R-27. pfiPrimerInfo: Request for additional information in the Primer

Classification: Doc Suggestion
Part: 0 (Primer)
Status: Closed
Originator: Doug Bunting

Description

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

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

Resolution

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



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

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Satoshi Nakamura

Description

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

Discussion

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

Resolution

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



R-29. pfiDatatypesComments: Remove request for comments from Datatypes

Classification: Editorial
Part: 2 (Datatypes)
Status: Closed
Originator: Martin Duerst

Description

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

Resolution

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.



R-30. pfiregexXmlCharRef: Request for clarification of regex notation

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: Martin Duerst

Description

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

Resolution

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.



R-31. pfianyURI: anyURI and xml:base

Classification: Clarification w/Erratum
Part: 2 (Datatypes)
Status: Closed
Originator: James Clark

Description

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

Resolution

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.



R-32. pfipublic: Type of public attribute of notation

Classification: Unclassified
Part: 1 (Structures)
Status: Closed
Originator: Jeff Rafter

Description

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

Discussion

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.

Resolution

Change made as part of erratum E1-16



R-33. pfiIdConstraint: Request for clarification of identity constraint rules

Classification: Clarification/Error
Part: 0,1 (Primer, Structures)
Status: Closed
Originator: Neil Graham

Description

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

Discussion

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

Resolution

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



R-34. pfisimpleTypefinal: Potential problem with description of final for simpleType in Structures

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Choi Jongwon

Description

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:

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

And, shouldn't the following rules be stated?

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

Discussion

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

Resolution

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:

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



R-35. pficharClassambig: Regular expression grammar for charClass is ambiguous

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: Satoshi Nakamura

Description

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

Discussion

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

Resolution

Erratum item E2-10 has been created.



R-36. pfiPrimerTextfont: Font of text in section 2.5.2 of Primer incorrect

Classification: Editorial
Part: 0 (Primer)
Status: Closed
Originator: Jason Stallion

Description

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

Resolution

Erratum E0-17 added.



R-37. pfiISO8601link: The link to ISO 8601 in the Datatypes spec doesn't work

Classification: Editorial
Part: 2 (Datatypes)
Status: Closed
Originator: Tony Coates

Description

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

Resolution

Erratum E2-42 added.



R-38. pfifractionDigits: Missing constraint for fractionDigits?

Classification: Clarification w/Erratum
Part: 2 (Datatypes)
Status: Closed
Originator: Kevin Yancey

Description

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

Discussion

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.

Resolution

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.



R-39. pfiDTDforSchema: Error in the DTD for Schemas in Structures spec

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Paul V. Biron

Description

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

Discussion

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

Resolution

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.



R-40. pfiregex: Clarification of the regex language in Datatypes

Classification: Clarification w/Erratum
Part: 2 (Datatypes)
Status: Closed
Originator: Paul V. Biron

Description

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

Resolution

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.



R-41. pfiregexProd10: Error in production 10 of regex in Datatypes

Classification: Error
Part: 2 (Datatypes)
Status: Errata Proposed
Originator: Paul V. Biron

Description

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

Resolution

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.



R-42. pfichoicechoice: Potential problem with particle derivation Choice:Choice rules

Classification: Future Requirement
Part: 1 (Structures)
Status: Closed
Originator: Achille Fokoue

Description

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

Resolution

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.



R-43. pfiPrimerTable1: Imprecise text in Table 1 of Primer

Classification: Unclassified
Part: 0 (Primer)
Status: Closed
Originator: Donald Gignac

Description

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

Resolution

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.



R-44. pfiPrimerSchemaLoc: Grammatical errors in section 5.6 of the Primer

Classification: Editorial
Part: 0 (Primer)
Status: Closed
Originator: Donald Gignac

Description

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

Resolution

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.



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

Classification: Editorial
Part: 0 (Primer)
Status: Closed
Originator: Donald Gignac

Description

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

Resolution

Erratum E0-16 added.



R-46. pfiIdConstrAnnot: Minor inconsistency in definition of Identity Constraints

Classification: Error, Future Requirement
Part: 1 (Structures)
Status: Closed
Originator: Mary Holstege

Description

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

Discussion

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

Resolution

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



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

Classification: Clarification w/erratum
Part: 1 (Structures)
Status: Closed
Originator: Henry Zongaro

Description

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

Discussion

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

Resolution

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.



R-48. pfiLexgMonth: Lexical representation of gMonth is inconsistent wrt ISO 8601

Classification: Error
Part: 0,2 (Primer, Datatypes)
Status: Closed
Originator: Henry Zongaro

Description

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

Resolution

The WG has agreed this is an error.

Errata E0-15 and E2-12 added.



R-49. pfiYr0000: ISO 8601:2000 defines 0000 as a valid year

Classification: Unclassified
Part: 2 (Datatypes)
Status: In progress
Originator: Henry Zongaro

Description

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

Discussion

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



R-50. pfiappInfo: "appInfo" element in Primer vs. "appinfo" element in Structures

Classification: Error
Part: 0 (Primer)
Status: Closed
Originator: Scott Means

Description

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

Discussion

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

Resolution

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

Erratum E0-14 added.



R-51. pfiPrimer2.3: Inaccurate text in section 2.3 of the Primer

Classification: Clarification
Part: 0 (Primer)
Status: Closed
Originator: Mark Hurley

Description

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

Resolution

The commentator misunderstood; the Primer is correct.



R-52. pfiCircularAttrGrp: Missing constraint for indirect circular attribute group?

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Sandy Gao

Description

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

Discussion

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

Resolution

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



R-53. pfiInclude: Request for clarification of include

Classification: Clarification
Part: 1 (Structures)
Status: Closed
Originator: Sandy Gao

Description

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

Resolution

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



R-54. pfiur-type: Request for clarification of ur-type

Classification: Clarification w/erratum
Part: 1 (Structures)
Status: Closed
Originator: Sandy Gao

Description

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

Discussion

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

Resolution

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



R-55. pfiPrimerTable2: Typo in table 2 of the Primer

Classification: Editorial
Part: 0 (Primer)
Status: Closed
Originator: Bill Thompson

Description

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

Resolution

Erratum E0-13 added.



R-56. pfiDerivedDatatypes: Grammatical error in section 2.5.2 of Datatypes spec

Classification: Editorial
Part: 2 (Datatypes)
Status: Errata Drafting
Originator: Donald Gignac

Description

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



R-57. pfiTypoAssessment: Inconsistent capitalization in section 2.1 of Structures

Classification: Editorial
Part: 1 (Structures)
Status: Closed
Originator: Donald Gignac

Description

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

Resolution

Erratum E1-42 added.



R-58. pfiPrimerAppC: Errors in example in Appendix C of Primer

Classification: Editorial
Part: 0 (Primer)
Status: Closed
Originator: Donald Gignac

Description

  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

Resolution

Erratum E0-12 added.



R-59. pfiPrimerAppCSugg: Suggested changes for Appendix C of Primer

Classification: Unclassified
Part: 0 (Primer)
Status: Closed
Originator: Donald Gignac

Description

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

Resolution

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.



R-60. pfiRestrictionSforS: Problem with particle derivation rules and the Schema for Schemas

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Henry S. Thompson

Description

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

Resolution

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



R-61. pfisignAllowed: Typo in section D.3.1 "Sign Allowed" of Datatypes spec

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: Thomas Broyer

Description

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

Resolution

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.



R-62. pfiIdConstrWhiteSp: Whitespace and identity constraint XPath expressions

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Henry S. Thompson

Description

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

Resolution

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.



R-63. pfiUnionExmp: Suggested change for union example in section 2.5.1.3 of Datatypes spec

Classification: Clarification w/erratum
Part: 2 (Datatypes)
Status: Closed
Originator: Donald Gignac

Description

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

Resolution

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.



R-64. pfiComplexTypeMapping: Issue with complex type property mapping rules for content type

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Asir Vedamuthu

Description

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.

Discussion

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

Resolution

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.



R-65. pfiWildCardConstr: Issues with the rules for wildcard union, subset, and intersection

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Sandy Gao

Description

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

    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

Resolution

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.



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

Classification: Error
Part: 1,2 (Structures, Datatypes)
Status: Closed
Originator: Asir Vedamuthu

Description

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

Resolution

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



R-67. pfiTypeDerivation: A question about type derivation and anonymous types

Classification: Clarification w/erratum, Future Requirement
Part: 0,1 (Primer, Structures)
Status: Closed
Originator: Lisa Martin

Description

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

Discussion

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

Resolution

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



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

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Alexander Falk

Description

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

Discussion

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

Resolution

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.



R-69. pfiregexcharRange: Problem in the regex grammar for charRange

Classification: Error
Part: 0,2 (Primer, Datatypes)
Status: Closed
Originator: Alexander Falk

Description

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 last item contradicts production [17] of the grammar.

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

Discussion

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.



R-70. pfiS4STypo: Typo in the Schema for Schemas

Classification: Editorial
Part: 2 (Datatypes)
Status: Closed
Originator: Eric van der Vlist

Description

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

Resolution

Erratum E2-29 added.



R-71. pfielemDeclConsist: Editorial error in the text for Element Declarations Consistent

Classification: Editorial
Part: 1 (Structures)
Status: Closed
Originator: Henry S. Thompson

Description

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

Resolution

Erratum E1-28 added



R-72. pfiAppETypo: Typo in appendix E of Structures

Classification: Editorial
Part: 1 (Structures)
Status: Errata Drafting
Originator: Elliotte Rusty Harold

Description

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



R-73. pfiAttrUse: Question about unions of attribute uses

Classification: Clarification w/erratum
Part: 1 (Structures)
Status: Errata Drafting
Originator: Lisa Martin

Description

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

Resolution

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



R-74. pficircularSubstGrp: Missing constraint for circular substitution groups?

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Henry S. Thompson

Description

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

Resolution

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



R-75. pfimaxExclusive: Potential problem with the rules for maxExclusive

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: Eric van der Vlist

Description

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

Resolution

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.



R-76. pficontentTypeEmpty: Question about content type EMPTY

Classification: Clarification
Part: 1 (Structures)
Status: Closed
Originator: Lisa Martin

Description

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

Resolution

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



R-77. pfiIdConstInclude: Issue to do with identity constraints and chameleon include

Classification: Clarification w/erratum, Future Requirement
Part: 1 (Structures)
Status: Errata Drafting
Originator: Jeni Tennison

Description

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

Resolution

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.



R-78. pfiSubstGrpUPA: Issue to do with definition of substitution groups, block, and UPA

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Sandy Gao

Description

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

Discussion

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

Resolution

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



R-79. pfiValidTypeDer: Ambiguity in statements about valid type derivation

Classification: Error
Part: 1 (Structures)
Status: Errata Drafting
Originator: Sandy Gao

Description

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

Resolution

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



R-80. pfiother: Meaning of ##other

Classification: Error
Part: 0,1 (Primer, Structures)
Status: Closed
Originator: Amy Moulton

Description

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

Discussion

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

Resolution

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.



R-81. pfiPrimerIDConst: Error in Primer example of identity constraints

Classification: Error
Part: 0 (Primer)
Status: Closed
Originator: Priscilla Walmsley

Description

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

Resolution

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.



R-82. pfiPrimerEdErrors: Three editorial errors in the Primer

Classification: Unclassified
Part: 0 (Primer)
Status: Closed
Originator: Priscilla Walmsley

Description

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

Resolution

Errata E0-7,8,9 added.



R-83. pfitoken: Token should exclude #xD from lexical and value spaces

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: Henry S. Thompson

Description

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

Resolution

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.



R-84. pfitoken: Can final="extension" for simpleType?

Classification: Clarification w/erratum
Part: 1 (Structures)
Status: Errata Drafting
Originator: Priscilla Walmsley

Description

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:

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

Discussion

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

Resolution

Resolved at the March 8 telecon to class R-84 as clarification with erratum and change the Structures spec to agree with Datatypes as regards final='extension' on simple types.

R-85. pfiQName: Request for clarification of QName type

Classification: Clarification w/erratum
Part: 2 (Datatypes)
Status: Errata Drafting
Originator: Eric Van der VList

Description

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

Discussion

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.

Resolution

Henry Thompson to draft erratum text reflecting discussion above.



R-86. pfiUPA: Request for clarification of UPA

Classification: Clarification w/erratum
Part: 1 (Structures)
Status: Closed
Originator: Sandy Gao

Description

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

Resolution

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



R-87. pfiStruct3.4.2: Error in section 3.4.2 of Structures

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Stanley Guan

Description

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

Discussion

Henry's response: Yes.

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

Resolution

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.



R-88. pfiNOTATION: Suggested changes to clarify NOTATION

Classification: Clarification w/erratum
Part: 2 (Datatypes)
Status: Closed
Originator: Eric van der Vlist

Description

The commentator suggests:

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

Discussion

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

Resolution

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.



R-89. pfiinteger: Is a trailing decimal point permitted for integer?

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: Henry Zongaro

Description

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

Discussion

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

Resolution

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.



R-90. pfidateTime: Questions about the lexical and canonical rep'ns of dateTime

Classification: Error
Part: 2 (Datatypes)
Status: Errata Drafting
Originator: Henry Zongaro

Description

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:

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

Discussion

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

Resolution

  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.



R-91. pfigrpRedefExt: Optional self-reference in group redefinition

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Henry S. Thompson

Description

The extension variant of group redefinition:

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



R-92. pfigrpRedefine: Clarification required for group redefinition

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Henry S. Thompson

Description

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



R-93. pfianyAttrRestrict: Problem with derivation by restriction and anyAttribute

Classification: Error w/erratum
Part: 1 (Structures)
Status: Closed
Originator: Kohsuke Kawaguchi

Description

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

Discussion

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



R-94. pfiIdConsRestrict: Issues with identity constraints and derivation by restriction

Classification: Clarification w/erratum, Future requirement
Part: 1 (Structures)
Status: Errata Drafting
Originator: Khaled Noaman/Henry S. Thompson

Description

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

Discussion

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

Resolution

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.



R-95. pfiPrimerPDF: Request for PDF version of the Primer

Classification: Doc Suggestion
Part: 0 (Primer)
Status: Closed
Originator: Kenneth Geisshert

Description

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

Resolution

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



R-96. pfiAttrScope: Problem with scope property of attributes

Classification: Error
Part: 1 (Structures)
Status: Errata Drafting
Originator: Henry S. Thompson

Description

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

Resolution

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.



R-97. pfiCanonFloat: Problem with canonical rep'n of float/double

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: Ashok Malhotra

Description

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

Resolution

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



R-98. pfiCanonQName: Question about the canonical rep'n of QName

Classification: Error
Part: 2 (Datatypes)
Status: In progress
Originator: Sandy Gao

Description

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

Discussion

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.



R-99. pfilengthFacet: Issue re: the length facet for NMTOKENS, IDREFS, ENTITIES

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: Sandy Gao

Description

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

Resolution

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.



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

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Sandy Gao

Description

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

Discussion

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

Resolution

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



R-101. pfiUPAGrp: Issue re: UPA and groups

Classification: Clarification w/erratum
Part: 1 (Structures)
Status: Closed
Originator: Sandy Gao

Description

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

Discussion

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

Resolution

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.



R-102. pfisimpleTypeRestrict: Errata in restriction constraints wrt simple type defns?

Classification: Error
Part: 1,2 (Structures,Datatypes)
Status: Closed
Originator: Henry S. Thompson

Description

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

Resolution

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



R-103. pfiPSVIDefn: The term PSVI needs to be defined

Classification: Editorial
Part: 1 (Structures)
Status: Closed
Originator: Ross Thompson

Description

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

Resolution

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



R-104. pfiIntegerFacets: Primer question re: integer and the fractionDigits facet

Classification: Clarification w/erratum
Part: 0 (Primer)
Status: Closed
Originator: Rieks van der Straaten

Description

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

Discussion

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

Resolution

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

Erratum E0-23 added.



R-105. pfiSchemaComponent: Comment re: identity constraints property in Schema component

Classification: Future Requirement
Part: 1 (Structures)
Status: Closed
Originator: Henry S. Thompson

Description

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

Resolution

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.



R-106. pfiQNameFacets: Clarification requested re: facets for QName type

Classification: Clarification w/Erratum
Part: 2 (Datatypes)
Status: Closed
Originator: Anli Shundi

Description

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

Discussion

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:

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.

Resolution

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.



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

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Henry S. Thompson

Description

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

Discussion

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

Resolution

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.



R-108. pfiFloatRounding: Clarification requested re: rounding of floats

Classification: Unclassified
Part: 2 (Datatypes)
Status: In progress
Originator: Michael Sperberg-McQueen

Description

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

Discussion

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



R-109. pfiFacetConstraints: Mismatch between Parts 1 and 2 in the area of facet constraints

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Martin Gudgin

Description

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

Discussion

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

Resolution

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



R-110. pfiTotalDigits: Error in example in section 4.3.11 of Datatypes?

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: Sandy Gao

Description

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

Resolution

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.



R-111. pfiappInfoAttr: Why are foreign attributes not permitted for appinfo and documentation?

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Eric van der Vlist

Description

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

Discussion

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



R-112. pfiQNameResolution: A question about QName Resolution (Schema Document)

Classification: Error w/erratum
Part: 1 (Structures)
Status: In progress
Originator: Sandy Gao

Description

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:

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

Resolution

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.



R-113. pfiall: A question about all content models

Classification: Clarification w/erratum
Part: 1 (Structures)
Status: Closed
Originator: Lisa Martin

Description

"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

Resolution

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



R-114. pfiInfoset: Schema infoset fix-ups

Classification: Unclassified
Part: 1 (Structures)
Status: In progress
Originator: Jonathan Marsh

Description

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

Discussion

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:

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



R-115. pfiAttrQName: Validating attributes with default value of type QName

Classification: Unclassified
Part: 1,2 (Structures, Datatypes)
Status: In progress
Originator: Ashok Malhotra

Description

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

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



R-116. pfipatternType: Question about the type of a pattern value

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: Closed
Originator: Ross Thompson

Description

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

Resolution

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.



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

Classification: Error w/erratum
Part: 1 (Structures)
Status: Closed
Originator: Henry S. Thompson

Description

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

Discussion

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

Resolution

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



R-118. pfidateTimeValue: Questions about the value space for dateTime

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: Closed
Originator: Michael Kay

Description

  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

Discussion

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

Resolution

Erratum E2-41 addresses this issue. Discussed/resolved at the June 12, 2003 telecon.

R-119. pfidateValue: Question about the value space for date

Classification: Clarification w/erratum
Part: 2 (Datatypes)
Status: Closed
Originator: Michael Kay

Description

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

Discussion

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

Resolution

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.



R-120. pfidateCanonical: Question about the canonical representation of date

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: Michael Kay

Description

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

Discussion

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

Resolution

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.



R-121. pfiPrimerExmp5.4: Import example in section 5.4 of Primer incorrect

Classification: Error
Part: 0 (Primer)
Status: Closed
Originator: Jeffrey Stephenson/Henry S. Thompson

Description

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

Resolution

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.



R-122. pfiSubGrpRestrict: Issue re: restricting substitution groups

Classification: Error
Part: 1 (Structures)
Status: Errata Drafting
Originator: Eric van der Vlist

Description

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

Discussion

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

Resolution

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



R-123. pfiRedefRedef: A question about redefining redefines

Classification: Clarification without erratum
Part: 1 (Structures)
Status: Closed
Originator: Mark Feblowitz

Description

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?

Discussion

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

Resolution

Discussed and resolved at the June 12, 2003 telecon:
RESOLVED: to classify R-123 as clarification without erratum.
ACTION: Sandy Gao to send Mark Feblowitz a copy of SG's note explaining the logic of our decision.

R-124. pfiPSVIProp: A question about PSVI properties

Classification: Editorial/Future Requirement
Part: 1 (Structures)
Status: Errata Drafting
Originator: Lisa Martin

Description

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?



R-125. pfiStruct4.3.2: Editorial error in section 4.3.2 of Structures

Classification: Editorial
Part: 1 (Structures)
Status: Closed
Originator: Wojtek Murawski

Description

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

Resolution

Erratum E1-34 added



R-126. pfiPrimerSubGroup: Suggested change for the Primer re: substitution group members

Classification: Unclassified
Part: 0 (Primer)
Status: Closed
Originator: Simon Cox

Description

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

Resolution

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.



R-127. pfiTimeMidnight: Distinction between 00:00:00 and 24:00:00 for time datatype?

Classification: Clarification w/erratum
Part: 2 (Datatypes)
Status: Errata Drafting
Originator: Henry Zongaro

Description

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

Resolution

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.



R-110b. pfiFractionDigitsSpace: Does the fractionDigits facet apply to the value space or lexical space?

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: Henry Zongaro

Description

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

Discussion

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.

Resolution

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.



R-128. pfigYearLeadingZero: Question re: leading zeros for gYearMonth and gMonth

Classification: Clarification w/erratum
Part: 2 (Datatypes)
Status: Errata Drafting
Originator: C.M. Sperberg-McQueen

Description

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

Discussion

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



R-129. pfiS4SId: type of id attr on schema elt

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Henry S. Thompson

Description

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

Resolution

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



R-130. pfiLangPattern: Pattern of language type in XMLSchema.xsd

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: Lin Yeng Husband

Description

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

Resolution

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.



R-131. pfiDurationTypo: Typo in description of duration in datatypes

Classification: Editorial
Part: 2 (Datatypes)
Status: Closed
Originator: Richard Emberson

Description

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

Resolution

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.



R-132. pfiCanonicalURIs: Equiv comparisons on anyURI

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: Errata Drafting
Originator: Paul V. Biron

Description

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

Resolution

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



R-133. pfiS4SXPath: Regex for XPath in S4S invalid

Classification: Error w/erratum
Part: 1 (Structures)
Status: Errata Drafting
Originator: Daniel Veillard

Description

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

Resolution

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



R-134. pfiRegexPosCharRange: Treatment of ^ in regexes

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: In progress
Originator: James Clark

Description

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

Discussion

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



R-135. pfiHighSurrogates: Question about surrogate characters in F.1.1

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: James Clark

Description

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

Resolution

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.



R-136. pfiXPathSelector: Question about selector XPath expressions

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Rahul Srivastava

Description

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

Discussion

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

Resolution

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.



R-137. pfiSubstGrpLocals: Can substitution groups contain local elements?

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Jerome Simeon

Description

Can subsitution groups contain local elements?

Discussion

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

Resolution

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.



R-138. pfiS4SanySimpleType: The S4S contains derivations with anySimpleType as the base

Classification: Clarification w/erratum
Part: 1 (Datatypes,Structures)
Status: Closed
Originator: Aung Aung

Description

  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

Discussion

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

Resolution

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

Henry Thompson to draft erratum:

Erratum incorporated within that of R-54.



R-139. pfiAppDMidnight: Appendix D of datatypes does not permit 24:00 for date/time types

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: James Clark

Description

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

Discussion

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

Resolution

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.



R-140. pfiLeapSeconds: dateTime order relation and leap seconds

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: In progress
Originator: James Clark

Description

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

Discussion

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.



R-141. pfiAppBdateTimeOrder: Changes suggested re: dateTime order relation

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: In progress
Originator: James Clark

Description

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

Discussion

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.



R-142. pfigMonthDayOrder: Order relation for gMonthDay, gMonth, gDay

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: Closed
Originator: James Clark

Description

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

Discussion

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

Resolution

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.



R-143. pfiS4SanyAttr: Subtle bug in schema doc. for schemas

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Henry S. Thompson

Description

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

Discussion

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

Resolution

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.



R-144. pfiDurationDateTime: Adding durations to dateTime

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: Errata Drafting
Originator: James Clark

Description

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

Resolution

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



R-145. pfileapSecValid: Leap second validation

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: Errata Drafting
Originator: James Clark

Description

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

Resolution

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.



R-146. pfiDbleLeapSec: Double leap seconds

Classification: Clarification
Part: 2 (Datatypes)
Status: Closed
Originator: James Clark

Description

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

Discussion

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



R-147. pfiLexicalDuration: Lexical form of duration components

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: James Clark

Description

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

Discussion

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

Resolution

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.



R-148. pfiDateTimeSeconds: Trailing decimal point in seconds field of dateTime and time

Classification: Unclassified
Part: 2 (Datatypes)
Status: In progress
Originator: James Clark

Description

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

Resolution

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.



R-149. pfinonPositiveInt: Is +0 allowed as a nonPositiveInteger in lexical form?

Classification: Clarification w/erratum
Part: 2 (Datatypes)
Status: Closed
Originator: James Clark

Description

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

Discussion

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

Resolution

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.



R-150. pfiIntlDigitChars: Are international digit characters allowed for date/time types?

Classification: Clarification w/erratum
Part: 2 (Datatypes)
Status: Closed
Originator: Sandy Gao

Description

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

Resolution

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.



R-151. pfiequalFacet: Questions about equal fundamental facet

Classification: Clarification w/erratum
Part: 2 (Datatypes)
Status: Closed
Originator: Sandy Gao

Description

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

Discussion

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

Resolution

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

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.



R-152. pfiTDesignator: When is T designator required with duration?

Classification: Error
Part: 2 (Datatypes)
Status: Closed
Originator: James Clark

Description

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

Discussion

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

Resolution

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.



R-153. pfipublicAttr: Is the public attribute of notation optional?

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Walter Waterfeld

Description

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

Discussion

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.

Resolution

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



R-154. pfiTypo5.1: Typo in section 5.1 of Structures?

Classification: Editorial
Part: 1 (Structures)
Status: Errata Drafting
Originator: Andrew Watt

Description

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

Resolution

Resolved at the July 2003 f2f to classify as editorial.



R-155. pfi4PrimerTypos: 4 Typos in the Primer

Classification: Editorial
Part: 0 (Primer)
Status: Closed
Originator: Priscilla Walmsley

Description

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

Resolution

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



R-156. pfiMixedSimple: Question about mixed="true" and simpleContent

Classification: Clarification w/Erratum
Part: 1 (Structures)
Status: Closed
Originator: Asir Vedamuthu

Description

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

Discussion

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

Resolution

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.



R-157. pfiNondeterministic: Question about non-deterministic content models

Classification: Clarification without erratum
Part: 1 (Structures)
Status: Closed
Originator: Ashok Malhotra

Description

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

Discussion

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

Resolution

Discussed at the Sept. 20 concall.

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



R-158. pfitopLevelAttr: topLevelAttribute and use=(optional|prohibited|required)

Classification: Future Requirement
Part: 1 (Structures)
Status: Closed
Originator: Asir Vedamuthu

Description

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

Discussion

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

Resolution

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



R-159. pfiAttrDefaults: Bug in the spec wrt attribute defaults

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: Henry S. Thompson

Description

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

Resolution

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.



R-160. pfitypeOverride: Question re: validity of type override with union type

Classification: Clarification without erratum
Part: 2 (Datatypes)
Status: Closed
Originator: Dave Hollander

Description

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:

Or another way

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

Resolution

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.



R-161. pfiQnameRes: QName resolution to components with no target namespace

Classification: Error
Part: 1 (Structures)
Status: Closed
Originator: James Clark

Description

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

Discussion

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

Resolution

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.



R-162. pfiStruct3.14.6: Errors in section 3.14.6 of Structures

Classification: Error w/erratum
Part: 1 (Structures)
Status: Closed
Originator: John Verhaeg

Description

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

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

Resolution

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



R-163. pfiS4SAnnotation: Inconsistency between S4S and schema component information re: annotations

Classification: Clarification w/erratum; Future Requirement
Part: 1 (Structures)
Status: Errata Drafting
Originator: David Stephenson

Description

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

Resolution

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


R-164. pfiPrimerPOXmp: Suggestion for change to Primer PO Example

Classification: Doc Suggestion
Part: 0 (Primer)
Status: Closed
Originator: Ben Clemens

Description

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

Resolution

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.



R-165. pfiAppHClarif: Clarification requested for statement in Appendix H of Structures

Classification: Clarification w/erratum
Part: 1 (Structures)
Status: Errata Drafting
Originator: James Clark

Description

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

Resolution

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.



R-166. pfiAppHClarif: Question re: xsi:type and skip

Classification: Error w/eratum
Part: 1 (Structures)
Status: Closed
Originator: Richard Tobin

Description

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

Discussion

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



R-167. pfiAttrAssessment: Question about assessment outcome for attributes

Classification: Clarification without erratum/Future Requirement
Part: 1 (Structures)
Status: Closed
Originator: Richard Tobin

Description

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

Resolution

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.



R-168. pfiErrorCodeMustfind: Question about error codes

Classification: Clarification
Part: 1 (Structures)
Status: Closed
Originator: Richard Tobin

Description

[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



R-169. pfiNotationPublic: Type of the public identifier of notations

Classification: Error w/erratum
Part: 1 (Structures)
Status: Closed
Originator: Paul V. Biron

Description

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.

Resolution

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.



R-170. pfiNotationPublic: Inconsistent use of the term "derived"

Classification: Future Requirement
Part: 1,2 (Structures,Datatypes)
Status: Closed
Originator: Berthold Daum

Description

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

Resolution

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



R-171. pfifixedValueConstraint: Question about fixed value constraint on element

Classification: Error w/erratum
Part: 1 (Structures)
Status: Errata Drafting
Originator: Richard Tobin

Description

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

Resolution

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



R-172. pfiurTypeIdConstr: Questions viz. when fields match element with the ur-type

Classification: Clarification w/erratum; Future Requirement
Part: 1 (Structures)
Status: Errata Drafting
Originator: Neil Graham

Description

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

Resolution

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



R-173. pfiDurationCanonical: Canonical form of duration

Classification: Clarification without erratum
Part: 2 (Datatypes)
Status: Closed
Originator: John Mercado

Description

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

Resolution

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



R-174. pfiDocumentProperty: Question re: PSVI document property

Classification: Future Requirement
Part: 1 (Structures)
Status: Closed
Originator: Elena Litani

Description

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

Discussion

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.

Resolution

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



R-175. pfinormalizedString: Questions re: normalizedString

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: Errata Approved
Originator: Michael Kay

Description

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

Resolution

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.



R-176. pfiRedundantMixed: Question about mixed in derivation by extension

Classification: Unclassified
Part: 1 (Structures)
Status: In progress
Originator: Masayasu Ishikawa

Description

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

Discussion

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



R-177. pfiIDList: Should list of IDs be allowed?

Classification: Clarification w/erratum
Part: 2 (Datatypes)
Status: Errata Proposed
Originator: Ashok Malholtra

Description

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

Discussion

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

Resolution

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



R-178. pfiAttrUseandFixed: Question about use and fixed for attributes

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Stanley Guan,Ashok Malholtra

Description

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



R-179. pfiEnumAnnotation: Defect in schema component model wrt enumeration and annotations

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: Errata Drafting
Originator: Asir Vedamuthu

Description

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

Discussion

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



R-180. pfiPSVIErrorCodes: Question about the schema error code property in the PSVI

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Sandy Gao

Description

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

Discussion

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



R-181. pfiListEquality: Question about equality of lists

Classification: Error w/erratum
Part: 1,2 (Structures,Datatypes)
Status: Errata Drafting
Originator: Stefan Wachter

Description

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

Discussion

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.



R-182. pfiUnionEquality: Question about equality and union types

Classification: Unclassified
Part: 1,2 (Structures,Datatypes)
Status: New
Originator: Stefan Wachter

Description

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

Discussion

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



R-183. pfiDefValue: Question about default values

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Sandy Gao

Description

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

Discussion

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



R-184. pfiPatternFacet: Question about pattern and union types

Classification: Unclassified
Part: 2 (Datatypes)
Status: New
Originator: Henry S. Thompson

Description

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

Discussion

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



R-185. pficalendarTypes: Question about cardinality of calendar types

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: Errata Drafting
Originator: Jeremy Carroll

Description

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

Discussion

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.



R-186. pfiMinMaxExclusive: Constraints for min/maxIn/Exclusive facets

Classification: Unclassified
Part: 2 (Datatypes)
Status: In progress
Originator: Sandy Gao

Description

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

Discussion

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



R-187. pfiMissingConstraints: Missing constraints

Classification: Unclassified
Part: 1,2 (Structures,Datatypes)
Status: New
Originator: Sandy Gao

Description

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

Discussion

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



R-188. pfiPrimerTable1AndUnion: Potential errors in the Primer

Classification: Unclassified
Part: 0 (Primer)
Status: New
Originator: Arthur E. Salwin

Description

  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



R-189. pfiRecursiveST: Recursive simple type definitions

Classification: Error
Part: 1 (Structures)
Status: Errata Drafting
Originator: Herve Verjus

Description

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

Discussion

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



R-190. pfiTruncationDefn: Truncation is not defined

Classification: Future Requirement
Part: 2 (Datatypes)
Status: Closed
Originator: Steven Taschuk

Description

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

Discussion

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



R-191. pfiePropsCorrect2: Question about e-props-correct.2

Classification: Error
Part: 1 (Structures)
Status: Errata Drafting
Originator: Sandy Gao

Description

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

Discussion

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.



R-192. pficanonicalDuration2: Revisiting issue about canonical form for duration

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: Errata Proposed
Originator: Steven Taschuk

Description

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

Discussion

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

Resolution

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



R-193. pfiprocessContentsSkip: Question re: processContents=skip

Classification: Error w/erratum
Part: 1 (Structures)
Status: Errata Drafting
Originator: Lisa Martin

Description

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

Discussion

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

Resolution

Discussed at the March 13, 2003 telecon.



R-194. pfiprocessContentsSkip2: Question re: processContents=skip

Classification: Clarification w/erratum
Part: 1 (Structures)
Status: Errata Drafting
Originator: Lisa Martin

Description

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

Discussion

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

Resolution

Discussed and classified at the May 13, 2003 telecon.



R-195. pfidateTime-order: Correct error in the description of order for dateTime

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: In progress
Originator: Dave Peterson

Description

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.

Discussion

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



R-196. pfiwarning-on-whitespace: Add health warning on use of whitespace facet on elements

Classification: Clarification w/erratum
Part: 2 (Datatypes)
Status: Errata approved
Originator: Francois Yergeau

Description

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.

Resolution

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.



R-197. pfiwhitespaceWarning: Add warning on whitespace processing

Classification: Clarification w/erratum
Part: 2 (Datatypes)
Status: In progress
Originator: Noah Mendelsohn

Description

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.



R-198. pfiUnionOfUnion: Problem with unions of unions

Classification: Error, Defer to 1.1
Part: 2 (Datatypes)
Status: Closed
Originator: Ed Merks

Description

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

Discussion

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

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

Resolution

At the June 12 2003 telecon: RESOLVED: Class R-198 as error to be fixed in 1.1.

R-199. pfifinalSimpletype: Problem with final for simple types

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: Errata Drafting
Originator: Lisa Martin/Ed Merks

Description

[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}?

Resolution

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.



R-200. pfiENTITYlists: Problem with erratum E1-18

Classification: Error w/erratum
Part: 1 (Structures)
Status: Errata Drafting
Originator: Sandy Gao

Description

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

Resolution

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.



R-201. pfiIRIlink: The link to IETF INTERNET-DRAFT: IRIs in the Datatypes spec is wrong

Classification: Editorial
Part: 2 (Datatypes)
Status: Closed
Originator: Paul Biron

Description

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

Resolution

Erratum E2-47 added.



R-202. pfiNumComps: How many components are there for complextype extensions?

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Schema WG

Description

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?



R-203. pfiminExclusivemaxExclusive: Inconsistency with constraints on min/maxExclusive

Classification: Unclassified
Part: 2 (Datatypes)
Status: New
Originator: Sandy Gao

Description

"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



R-204. pfiminMaxZero: ComplexType mapping rule issue: min=max=0

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Sandy Gao

Description

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



R-205. pfimixedTypeContent: Question re: mixed on complexType and complexContent

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Sandy Gao

Description

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



R-206. pfiIdConstrFields: Can fields identity nodes with types having simpleContent?

Classification: Clarification w/erratum
Part: 1 (Structures)
Status: Errata Drafting
Originator: Rainer Becker (via Henry S. Thompson)

Description

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

Resolution

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.



R-207. pfiWildcardRestriction: Question about wildcard restriction

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Dare Obasanjo

Description

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



R-208. pfiNOTATIONLexicalSpace: Question about the lexical space of NOTATION types

Classification: Unclassified
Part: 2 (Datatypes)
Status: New
Originator: Sandy Gao

Description

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



R-209. pfiMissingIdAttr: appinfo and documentation elements have no id attribute

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Dmitry Trifonov

Description

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



R-210. pfiPrimerAmbiguity: Ambiguity in the Primer

Classification: Unclassified
Part: 0 (Primer)
Status: New
Originator: Emmanuel Languillat

Description

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



R-211. pfiAnnotationAttrs: The {attributes} property on the Annotation schema component

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: C.M. Sperberg-McQueen

Description

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



R-212. pfiElementLocallyValid: Question about VR Element Locally Valid (Element) in Structures 3.3.4

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: C.M. Sperberg-McQueen

Description

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



R-213. pfiAttrWildCardRestr: Question about attribute wildcards and restriction

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Xan Gregg

Description

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



R-214. pfidoubleValueSpace: Question about the value space of double

Classification: Error w/erratum
Part: 2 (Datatypes)
Status: Errata Drafting
Originator: Sandy Gao

Description

[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

Resolution

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.



R-215. pfiwhitespaceIdConstr: Whitespace and identity constraints

Classification: Error w/erratum
Part: 1 (Structures)
Status: Errata Drafting
Originator: Tim Hanson

Description

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

Resolution

Discussed at the 2003-08-31 telecon to classify as an error with erratum, and instruct the editors to fix the pattern.



R-216. pfiNameAndTypeOK: Potential problem with Name and Type OK

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Sandy Gao

Description

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



R-217. pfiDerivValidRestr: Potential problem with Derivation Valid (Restriction, Complex)

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Sandy Gao

Description

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



R-218. pfiComplexContentSimpleContent: Clarification required for complexContent extending simpleContent

Classification: Error w/ erratum
Part: 1 (Structures)
Status: Errata Approved
Originator: Sandy Gao

Description

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

Resolution

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



R-219. pfiIdConstrListUnion: Does section 3.11.1 of part 1 need to refer to list, union?

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Schema WG

Description

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



R-220. pfiE1_17Issue: Problem with erratum E1-17

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Henry S. Thompson

Description

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



R-221. pfiDecimalExcessPrec: Question about decimal values with >18 digits

Classification: Clarification w/erratum
Part: 2 (Datatypes)
Status: In progress
Originator: John Tebbutt

Description

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.

Discussion

Discussed at the 2003/12/19 telecon: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Dec/0064.html



R-222. pfiDatatypesNamespace: Should XML Schema continue to define the XMLSchema-datatypes namespace?

Classification: Unclassified
Part: 2 (Datatypes)
Status: New
Originator: Schema WG

Description

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>


R-223. pfiPart1Xmp: Suggested change to an example in Structures

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: D. Schenk

Description

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



R-224. pfiMetachars: Questions about metacharacters in regular expressions

Classification: Unclassified
Part: 2 (Datatypes)
Status: New
Originator: Michael Sperberg McQueen

Description

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

Discussion

Note that items 1 and 2 are covered by R-41.



R-225. pfiFixedElemVal: Question about fixed element value with simple type

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Sandy Gao

Description

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



R-226. pfiSchemaLoc: Must the content of schemaLocation be a resolvable URL?

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Henry S. Thompson

Description

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



R-227. pfiIdConstrNil: identity constraints and xsi:nil

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Tim Hanson

Description

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



R-228. pfifractionDigitsXmp: Suggestion for changes in fractionDigits example in part 2

Classification: Unclassified
Part: 2 (Datatypes)
Status: New
Originator: Anli Shundi

Description

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



R-229. pfiTimeOrderRelation: Order relation on time

Classification: Unclassified
Part: 2 (Datatypes)
Status: New
Originator: Steve Hanna

Description

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



R-230. pfimaxOccurs0: Question on maxOccurs=0, particles and restriction

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Tim Daplyn

Description

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



R-231. pfieumerationComps: Enumeration restrictions are unclear

Classification: Unclassified
Part: 1,2 (Structures,Datatypes)
Status: New
Originator: Henry S. Thompson

Description

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



R-232. pfivacuousRedefinition: Vacuous Redefinition

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Michael Sperberg-McQueen

Description

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



R-233. pfixsiAttributes: Validation of xsi: attributes

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Henry S. Thompson

Description

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



R-234. pfiAnonTypeGlobalElements: Anonymous global type elements of same name in model group

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Kazumi Saito

Description

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



R-235. pfiNegZeroDecimal: Canonical rep'n of -0.0

Classification: Unclassified
Part: 2 (Datatyeps)
Status: New
Originator: Arjohn Kampman

Description

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

Discussion

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



R-236. pfiwhitespaceInteger: whitespace facet constrains value space of integer?

Classification: Unclassified
Part: 2 (Datatyeps)
Status: New
Originator: Dan Connolly

Description

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



R-237. pfiS4SErrors: Possible errors in the S4S

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: David Bau

Description

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



R-238. pfiPrimerEmptyContent: Primer Section 2.3 - Empty Content

Classification: Unclassified
Part: 0 (Primer)
Status: New
Originator: David Bau

Description

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

Discussion

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



R-239. pfiElementDeclsConsistent: Question re: Element Declarations Consistent

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: David Bau

Description

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

Discussion

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



R-240. pfiNSRecurseCheckCardinality: Question re: Particle Derivation OK (All/Choice/Sequence:Any -- NSRecurseCheckCardinality)

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Alessandro Triglia

Description

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

Discussion

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



R-241. pfiUnionRestr: Question re: Validation of an element restriction whose base type has the variety union

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Michael Marchegay

Description

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.

Discussion

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



R-242. pfifinalSimpleType2: Part 1: final attribute of simpleType

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Michael Kay

Description

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.



R-243. pfiAddingBackAttrs: Can an attribute prohibited by restriction be added back through a subsequent extension?

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Henry S. Thompson

Description

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

Discussion

See subsequent email on this thread.



R-244. pfiAppendixE: Clarification requested for Appendix E

Classification: Unclassified
Part: 2 (Datatypes)
Status: New
Originator: Joseph Fialli

Description

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

Discussion

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



R-245. pfiPart1Editorial: Editorial error in section 3.1.4 of Structures

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Dan Small

Description

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



R-246. pfiIDREFSspace: IDREFS and space

Classification: Unclassified
Part: 2 (Datatyeps)
Status: New
Originator: Walter Waterfeld

Description

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



R-247. pfilanguagetype: 2E PER: bracket missing in pattern for lexical space of xs:language

Classification: Unclassified
Part: 2 (Datatyeps)
Status: New
Originator: Walter Waterfeld

Description

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



R-248. pfi2EPart2Typos: 2E PER: Typos in 2E Datatypes spec

Classification: Unclassified
Part: 2 (Datatyeps)
Status: New
Originator: Anli Shundi

Description

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



R-249. pfiErratumE2-18: 2E PER: Objection to erratum E2-18

Classification: Unclassified
Part: 2 (Datatyeps)
Status: New
Originator: Bob Foster

Description

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



R-250. pfircase-MapandSum: 2E PER: Comments on rcase-MapAndSum

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Eric J. Schwarzenbach

Description

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



R-251. pfiEditorialMinMax: 2E PER: Probable editorial problem, mix/maxExclusive facets

Classification: Unclassified
Part: 2 (Datatypes)
Status: New
Originator: Dave Peterson

Description

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



R-252. pfiFinalBlock: Final/block, transitivity and restriction

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Henry S. Thompson

Description

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



R-253. pfiSchemaLocRedefine: Failure of schemaLocation to resolve for redefine

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Henry S. Thompson, Noah Mendelsohn

Description

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



R-254. pfiMergeUnion: Clarify merge/union of facets

Classification: Unclassified
Part: 2 (Datatypes)
Status: New
Originator: Xan Gregg

Description

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

Discussion

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



R-255. pfipatternFacet2: Value of pattern facet

Classification: Unclassified
Part: 2 (Datatypes)
Status: New
Originator: Xan Gregg

Description

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



R-256. pfiAttrWildcards: 2E PER: Attribute wildcards numbering problem

Classification: Unclassified
Part: 1 (Structures)
Status: New
Originator: Michael Kay

Description

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



R-257. pfiPercentEsc: Health warning needed about percent-escaping URIs

Classification: Unclassified
Part: 2 (Datatypes)
Status: New
Originator: XML Schema WG

Description

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.



R-258. pfiInclExcl: Need to resolve contradiction regarding inclusive and exclusive bounds

Classification: Unclassified
Part: 2 (Datatypes)
Status: New
Originator: Sandy Gao

Description

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.



R-259. pfiQNameBinding: Are QNames without prefix bindings type-valid?

Classification: Unclassified
Part: 2 (Datatypes)
Status: New
Originator: Mary Holstege and XML Schema WG

Description

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:

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: