XML Schema: Requirements and candidate requirements for version 1.1

Input from Straw Poll O-4.

This item was discussed in the meeting of 2004-01-22

This item was discussed in the Cannes face to face meeting of 2004-03-02. Phase 2 wording was amended and approved.

Mail from Ashok Malhotra and subsequent thread (member-only links)

There must be a canonical representation of duration, and a process for calculating the canonical representation from any other lexical representation. Currently, a period of one day and a period of 24 hours are considered two different values in the value space. They should be considered two different lexical representations of the same value.

See (member-only link) http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2001Jan/0215.html. See also http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0102.html : R-170.

Input from Straw Poll O-5.

Microsoft proposals, item 1.1 (member-only link)

Michael Kay (member-only link)

This item was mentioned in the meeting of 2003-09-18

This item was discussed in the meeting of 2003-10-03

This item was discussed in the meeting of 2004-01-09

This item was discussed in the meeting of 2004-06-11.

Input from Straw Poll O-5.

NOTE 2002-08-02: this needs to be analysed into its constituent items, and each item acted on individually.

Input from Straw Poll O-6

NOTE 2002-08-02: this needs to be analysed into its constituent items, and each item acted on individually.

This item was postponed in the meeting of 2004-04-22.

Input from Straw Poll O-7

This item was mentioned in the meeting of 2003-09-18

Input from Straw Poll O-12

Cf. RQ-135.

This item was discussed, and phase-1 agreement was reached, in the meeting of 2004-03-18. All we need to say to discharge this requirement is that restriction is transitive. The types derived by multiple restriction steps should also obey the wildcard. There was some doubt over whether the constructive rules of XML Schema 1.0 achieve this, but the definition of restriction in section 2 seems to entail it.

RESOLVED: our phase 1 agreement on RQ-007 is that it appears to be taken care of by the existing constructive rules. Phase 2 approval will be established by our accepting a proof that this is so.

In leaving the topic, MSM remarked that if we discharge requirement RQ-017 correctly, RQ-007 should follow automatically.

Input from:

James Clark: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000OctDec/0216

Judith A. Slein: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JanMar/0050

Matthew Fuchs: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JanMar/0052

Judith A. Slein: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JanMar/0053

Matthew Fuchs: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JanMar/0054

Judith A. Slein: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JanMar/0057

Straw Poll O-12

This item was discussed in the meeting of 2003-11-04

This item was postponed in the meeting of 2004-05-13. It may be taken up again in the context of the discussion of how best to support versioning.

Microsoft proposals, item 1.3 (member-only link)

Asir Vedamuthu(member-only link)

Input from Straw Poll O-12

This item was abandoned in the meeting of 2004-05-13.

Input from Straw Poll O-14

This item was discussed in the meeting of 2004-04-09.

This item was closed in the meeting of 2004-05-13. It has been overtaken by events: if RQ-17 succeeds, this has no referent in the spec.

Microsoft proposals, item 1.2 (member-only link)

Input from Straw Poll O-14

This item was closed in the meeting of 2004-05-13. It has been overtaken by events: if RQ-17 succeeds, this has no referent in the spec.

Input from :

This item was discussed in the meeting of 2003-09-05

This item was discussed in the meeting of 2003-09-11

This item was discussed in the meeting of 2003-09-17

This item was discussed in the meeting of 2003-09-26

This item was discussed in the meeting of 2003-10-02

This item was discussed in the meeting of 2003-11-03

Input from Straw Poll O-10

Henry Thompson, proposing a resolution for RQ-14, RQ-19, RQ-130 and RQ-131.

Input from Straw Poll O-10

Interacts with RQ-17.

This item was discussed in the meeting of 2004-04-09. We agreed that we would like to see the proposal written down. The minutes say “The description in the minutes may suffice as written proposal; if not, HT will write it up. Others to say if the minutes are insufficient.”

Further action is needed.

This item was discussed, and phase-1 agreement was reached, in the meeting of 2004-05-13.

Input from Straw Poll O-10

NOTE 2002-08-02: this item is unclear to the members of the WG present at the August 2002 face to face meeting; a clearer statement of the intended requirement is needed.

Clarified by Henry.

This item was mentioned in the meeting of 2003-09-18

This item was closed in the meeting of 2003-11-04. The issue has been classified as an erratum (R-105) and does not need to be taken care of as part of 1.1. Cf. also RQ-133.

Input from Straw Poll O-14

Interacts with several other requirements; proposals for this requirement also cover or affect RQ-11, RQ-12, RQ-15, RQ-146.

Confirmed as Requirement at 2002-08-02 F2F. We discussed reclassifying it and decided not to.

This item was discussed in the meeting of 2003-11-04

This item was discussed in the meeting of 2004-04-09.

This item was discussed in the meeting of 2004-04-15.

This item was discussed in the meeting of 2004-05-06.

This item was discussed in the meeting of 2004-05-07.

This item was discussed in the meeting of 2004-05-12.

This item was discussed in the meeting of 2004-05-20.

This item was discussed in the meeting of 2004-06-04.

Input from Straw Poll O-15

This item was discussed in the meeting of 2003-11-04

This item was discussed in the meeting of 2003-11-21; Noah Mendelsohn to draft a phase-1 proposal (making sure that foreign-namespace attributes are not lost).

This item was discussed, and phase-1 agreement was reached, in the meeting of 2004-03-18.

Henry Thompson, proposing a resolution for RQ-14, RQ-19, RQ-130 and RQ-131.

Input from Straw Poll O-5

This item was discussed in the meeting of 2003-09-17

This item was mentioned in the meeting of 2003-09-18

This item was discussed in the meeting of 2003-10-03

This item was discussed (and phase-1 agreement reached) in the meeting of 2003-10-09

This item was discussed in the meeting of 2003-10-10. The draft wording was returned to the editors for revision.

This item was discussed in the meeting of 2003-11-03

This item was discussed in the meeting of 2003-12-04; the editors submitted revised text that day.

This item was discussed and phase 2 wording was considered, amended, and approved in the meeting of 2003-12-18.

This item was discussed in the meeting of 2004-01-09.

This item was discussed in the meeting of 2004-06-11.

yearMonthDuration and dayTimeDuration as defined in XQuery and XPath Function and Operators

Input from Straw Poll O-7

This item was mentioned in the meeting of 2003-09-18

This item was discussed in the meeting of 2003-10-10

This item was discussed in the meeting of 2003-10-16

This item was discussed in the meeting of 2003-11-04. We agreed that yes, we will have BNF and/or regular expressions and that this constitutes agreement for phase 1. Details of the BNF and regexes are to be considered in phase 2.

This item was discussed in the meeting of 2004-01-09

This item was discussed in the meeting of 2004-04-29. The WG noted that we were (already) done with phase 1 agreement.

Alexander Falk (member-only link)

Input from Straw Poll O-15

This item was discussed, and phase-1 agreement was reached, in the meeting of 2004-04-22.

Input from Straw Poll O-16

This item was closed (because overtaken by events) in the meeting of 2004-04-23. It remains a requirement for the work of the Working Group, but it will be met by the Schema Component Designators draft, not by XML Schema 1.1. So it does not need to be tracked in this requirements list.

Input from Straw Poll O-7

Retained as desideratum 2 August 2002; this is important.

This item was discussed in the meeting of 2003-08-29

This item was discussed in the meeting of 2003-10-23

This item was discussed in the meeting of 2003-10-30

This item was discussed in the meeting of 2003-10-31

This item was discussed in the meeting of 2003-11-04

This item was discussed in the meeting of 2004-05-12.

This item was discussed in the meeting of 2004-05-27.

This item was discussed in the meeting of 2004-06-03.

This item was discussed in the meeting of 2004-06-11. (N.B. the available draft covers part but not all of the substance of our phase-1 agreement.)

Dave Peterson (member-only link)

Input from Straw Poll O-10

NOTE 2002-08-02: the meaning of this item is unclear to the members of the WG present at the August 2002 face to face; it needs to be clarified and either retained or dropped.

This item was reclassified as a non-goal in the meeting of 2004-03-18.

Input from Straw Poll O-12

This item was abandoned in the meeting of 2004-05-13.

Our comment of http://lists.w3.org/Archives/Public/www-xml-schema-comments/2001JanMar/0298 : March 2001: "There is sentiment in the WG towards allowing some form of exponential notation for decimals in future, but it would be explicit in instances (e.g. value="3E-10"), not implicit in type definitions."

Input from Straw Poll O-4

This item was discussed in the meeting of 2004-04-01. Phase 1 discussion was closed, because this item will succeed or fail with RQ-031.

Input from Straw Poll O-16

This item was postponed in the meeting of 2004-04-30.

Input from Straw Poll O-4

This item was discussed in the meeting of 2004-04-01. Phase 1 discussion was closed, because this item will succeed or fail with RQ-031.

Provide a datatype which retains trailing zeroes in the lexical representation of decimal numbers. More generally, provide a precision decimal type, in which each value is associated not only with a magnitude but also with a precision.

See http://www.w3.org/2000/12/xmlschema-crcomments.html#canonical-decimals : CR-42.

Input from Straw Poll O-4

Interacts with RQ-28, RQ-30 (the same proposal discharges all).

Changed to desideratum on telcon 2002-11-21. The rationale was that we already have a well developed proposal for this.

This item was discussed in the meeting of 2004-03-02

This item was discussed in the meeting of 2004-04-01. We reached phase-1 agreement on canonical forms and keeping a single NaN.

This item was discussed in the meeting of 2004-05-12. A proposal to reclassify it as a non-goal was discussed briefly, and postponed until late June.

Dave Peterson and Mike Cowlishaw (member-only link)

Latest from Dave Peterson (member-only link)

Input from Straw Poll O-7

NOTE 2002-08-02: there was some support for demoting this to a non-goal, on the grounds that it was too hard to get right for 1.1 and it would be better to wait and do it right in 2.0. The idea did not achieve consensus; some members of the WG believed they could define an abstract simple type mechanism which would achieve consensus in the WG.

This item was abandoned in the meeting of 2004-04-22. Three kinds of abstract simple types had been discussed: (a) an abstract numeric type from which the other numerics could be derived, (b) our old (pre-1.0) design for a complete hierarchy of abstract simple types, and (c) user ability to specify abstract = "true" for simple types, as can be done for complex types. It was clear in this meeting that there was no proposal on the table that commanded anything like consensus in the Working Group.

Dave Peterson (member-only link)

Microsoft proposals, item 2.2 (member-only link)

Key constraints to restrict which element types can be pointed to: Allow a schema author use key constaints to specify that a value (which otherwise behaves like an SGML or XML ID) is restricted to pointing at one (or more) particular element type(s)?

See (member-only link) http://www.w3.org/XML/Group/xmlschema-current/lcissues.html#typed-refs : LC-151.

Input from Straw Poll O-10

Discussion at http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Nov/0127.html

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

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

Input from Straw Poll O-11

NOTE 2002-08-02: there was some support at our face to face meeting for promoting this to desideratum, and some for removing it, and some for handling it as a clarification with erratum for XML Schema 1.0 Second Edition; there was most support for leaving it as an opportunistic desideratum. In the absence of consensus to move it, we left it alone. There was speculation that if we get good text for this, the WG might be willing to put it into 2E anyway.

This item was resolved in the meeting of 2004-03-18, with the observation that it is already possible to use inline schemas and that a task force is working on the area.

Input from Straw Poll O-11

NOTE 2002-08-02: there was some sentiment at our face to face meeting for demoting this to a non-goal, but there was not consensus.

This item was abandoned in the meeting of 2004-03-25. The consensus of the WG was that we should make no change here; some attribute this view to compatibility reasons, others to other reasons. The current status quo does in any case match what several commentators said was an acceptable fallback when the issue was discussed in 2000.

This is subsumed proposals to deal with R-17.

Input from Straw Poll O-15

This item was postponed in the meeting of 2004-04-30. It will stand or fall with the ‘landscape’ proposal for RQ-017 and friends. If that proposal succeeds, this requirement will be discharged; if not, we are unlikely to do this on its own.

This item was discussed in the meeting of 2004-05-20.

Asir Vedamuthu (member-only link)

Input from Straw Poll O-15

This item was postponed in the meeting of 2004-03-25.

This item was taken up again and discussed in the face to face meeting of 2004-05-13 but there was no consensus on the proposal. The item was again postponed.

This issue was also formerly known as co-occurrence (RQ-27; removed)

Input from Straw Poll O-13

Opportunistic desideratum for 1.1: At our meeting in August 2002, some members of the WG felt that co-constraints needed to be a requirement for 1.1, others that the feature is too complex to design in the time available and with the compatibility constraints agreed for 1.1. Some WG members thought an 80/20 solution would be easy to specify, and undertook to demonstrate this by doing so.

This item was abandoned in the meeting of 2004-03-25.

A request to reopen it was was received on 25 May from Fabio Vitali (member-only link).

Input from Straw Poll O-5

Input from Straw Poll O-5

Input from Straw Poll O-5

Input from Straw Poll O-6

Input from Straw Poll O-6

Input from Straw Poll O-8

Input from Straw Poll O-8

Input from Straw Poll O-8

Input from Straw Poll O-9

Input from Straw Poll O-9

Input from Straw Poll O-11

Input from :

Input from Straw Poll O-13

Input from Straw Poll O-14

Input from Straw Poll O-15

Input from Straw Poll O-15

Input from Straw Poll O-15

Input from Straw Poll O-15

Input from Straw Poll O-15

Input from Straw Poll O-16

Input from Straw Poll O-16

Input from Straw Poll O-16

Input from Straw Poll O-16

Input from Straw Poll O-8

Input from Straw Poll O-8

Input from Straw Poll O-9

Input from Straw Poll O-9

Input from Straw Poll O-10

Input from Straw Poll O-10

Input from Straw Poll O-10

Input from Straw Poll O-10

Input from Straw Poll O-11

Microsoft proposals, item 3.1 (member-only link)

Input from Straw Poll O-11

Input from Straw Poll O-12

Input from Straw Poll O-14

Input from Straw Poll O-14

Input from Straw Poll O-15

Input from Straw Poll O-15

Input from Straw Poll O-15

I18N WG position: We are very unhappy about the XML Schema WG's position on this matter. We have provided many use cases and consider this to be a very significant requirement. We request a commitment to include this capability in Schema 1.1.", http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2001Mar/0040 : "The XML Schema WG agreed to place this feature on the list of candidate requirements for XML Schema 1.1."

Input from Straw Poll O-15

Input from Straw Poll O-16

Input from Straw Poll O-16

Input from Straw Poll O-16

Input from Straw Poll O-6

Non-goal for 1.1: the only quick solution (magic) is ad hoc; a full solution for specifying case-folding of strings is complex and would take too long to be feasible for 1.1, even if there were consensus in the WG and community that it would be desirable, which there is not.

Input from Straw Poll O-6

Non-goal for 1.1: the type library is a separate work item, not part of XML Schema 1.1. (Note that some members of the WG do believe it should be integrated into 2.0, but there is not now consensus on this point.)

Input from Straw Poll O-16

Non-goal for 1.1: as a consequence of our discussion of the PSVI on 1 August 2002, the WG decided on 2 August 2002 to treat the proposal for a canonical form for schema documents or schemas as a non-goal for XML Schema 1.1. This topic will continue to be discussed as part of our work on use cases for access to the post-schema-validation information set.

Input from Straw Poll O-6

Non-goal for 1.1: it may be useful to define a special element for signaling control characters (analogous to the math-character element for special mathematical characters) and to place it in the type library. Some members of the WG felt that a special mechanism for handling legacy data did not belong in the specification of a schema language.

Input from Straw Poll O-8

Non-goal for 1.1: this is really a desideratum for the type library, not for XML Schema 1.1.

Input from Straw Poll O-9

Non-goal for 1.1: some WG members suggested that this item would require a new component type, and if so that it would be too big a change for 1.1. Some WG members would like it to be a non-goal for 2.0 as well. Some dissent.

Input from Straw Poll O-14

Non-goal for 1.1: this is redundant with restrictn-rules.

Input from Straw Poll O-16

Non-goal for 1.1: this appears no longer to be a desideratum on the part of the Query WG. And we have a desideratum to clarify the value space of anySimpleType, which should achieve most of the advantages hoped for from this item.

Input from Straw Poll O-8

Non-goal for 1.1: We decided on 2 August 2002 to make this a non-goal for 1.1. Two inconsistent rationales were given: this is out of scope, and this is in scope but too hard to solve for 1.1.

Input from Straw Poll O-10

Non-goal for 1.1: We decided 2 August 2002 to make this a non-goal for XML Schema 1.1, on the grounds that we don't know how to solve it now (and thus it's not feasible to solve it for 1.1).

Input from Straw Poll O-15

Non-goal for 1.1: We decided 2 August 2002 to make this a non-goal for XML Schema 1.1, on the grounds that though it is important, it does not appear urgent and may represent too large a change for 1.1.

Input from Straw Poll O-15

Non-goal for 1.1: We decided 2 August 2002 to make this a non-goal for XML Schema 1.1, on the grounds that though it is important, it does not appear urgent and may represent too large a change for 1.1.

Non-goal for 1.1: We decided 2 August 2002 to make this a non-goal: it raises compatibility issues, may break security applications (?), would be difficult to do in a way that generates consensus, and seems likely to be a significant bug-source if rushed. Some strong sentiment for revisiting this for 2.0.

Input from Straw Poll O-16

Non-goal for 1.1: we decided 2 August 2002 to make this a non-goal, with two incompatible rationales: (1) it is a desirable goal but not achievable in 1.1, and (2) there is nothing in 1.0 which in fact precludes streaming processors.

This item was discussed in the meeting of 2004-05-12; there was no consensus, the WG being equally divided between the desire to adopt the proposal and the desire to abandon the desideratum. We agreed to postpone further discussion; the topic may come up again. If it proves useful in supporting versioning, there is a higher likelihood of adoption.

Xan Gregg (member-only link)

This item was discussed in the meeting of 2003-11-21

The definition of the language datatype has been changed in 2e to permit only those lexical forms allowed by RFC 3066.

Henry argues IDs are legacy and we should allow only one ID value per element. Thus, outlaw list of ID, attribute and child element having ID vales.

This item was abandoned in the meeting of 2004-04-30.

Henry Thompson. (member-only link)

On the Nov 14, 2003 telcon we decided that lists of IDs were allowed but would not serve as identifiers in the sense that an ID attribute does. Ashok Malhotra to draft note.

This item was discussed in the meeting of 2003-11-04. It's a non-goal: users who want only URIs, not URI references, can define their own subtype in the obvious way.

This item was mentioned in the meeting of 2003-09-18

This item was discussed in the meeting of 2003-11-04

This item was in the meeting of 2004-04-29.

This item was abandoned in the meeting of 2004-05-12.

This item was discussed in the meeting of 2003-11-04

This item was classified as Non-goal in the meeting of 2004-03-11. The WG's reasoning was that this is subsumed by R-132 and doesn't need to be a separate requirement.

This item was discussed in the meeting of 2004-04-22.

This item was classified as a non-goal in the meeting of 2004-03-11

This item was abandoned in the meeting of 2004-03-25.

This item was discussed in the meeting of 2004-04-30. We did not achieve consensus on instructions to the editors.

Berthold Daum

This item was discussed in the meeting of 2003-10-24

This item was discussed in the meeting of 2003-11-21. Let prohibited win? Treat as error on component? Handle symmetrically with type? Need to make sure we handle possible re-introduction of attributes prohibited in the base. Need a phase-1 proposal.

This item was discussed, and phase-1 agreement was reached, in the meeting of 2004-03-25.

Dave Peterson (member-only link)

Approved for addition in Chapel Hill: http://www.w3.org/XML/2002/10/xml-schema-ftf-minutes#xs11.3111

This may have been solved by accepting Dave Peterson's proposal for R-120 erratum for R-120 (member-only link)

This item was discussed in the meeting of 2003-09-17

This item was discussed in the meeting of 2004-03-01

Dave Peterson erratum for R-120 (member-only link)

Approved for addition in Chapel Hill: http://www.w3.org/XML/2002/10/xml-schema-ftf-minutes#xs11.3111.

This may have been solved by accepting the erratum for R-120 (member-only link) which includes a note about allowing year 0000.

This item was mentioned in the meeting of 2003-09-18

Dave Peterson erratum for R-120 (member-only link)

This item was discussed, and phase-1 agreement was reached, in the meeting of 2004-05-13.

This item was discussed in the meeting of 2003-11-21. Paul Biron to produce phase-1 proposal.

This item was discussed, and phase-1 agreement was reached, in the meeting of 2004-03-19.

Dave Peterson and subsequent thread (member-only links)

This item was classified as Opp.Des. in the meeting of 2004-04-29.

This item was in the meeting of 2004-04-29.

This item was abandoned in the meeting of 2004-05-12.

This item was discussed in the meeting of 2003-11-04

This item was discussed, and phase-1 agreement was reached, in the meeting of 2004-03-19.

On July 25 telcon agreed to add commets that resulted in R-163 to this issue. See material from R-163 copied below:

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.

Henry Thompson

as well as an earlier posting with an example: David Stephenson

This item was discussed in the meeting of 2003-11-21

This item was classified as Req in the meeting of 2004-03-11.

This item was discussed, and phase-1 agreement was reached, in the meeting of 2004-03-26.

Henry Thompson, proposing a resolution for RQ-14, RQ-19, RQ-130 and RQ-131.

This item was classified as Req in the meeting of 2004-03-11.

This item was discussed, and phase-1 agreement was reached, in the meeting of 2004-03-26.

Henry Thompson, proposing a resolution for RQ-14, RQ-19, RQ-130 and RQ-131.

This item was mentioned in the meeting of 2003-09-18

This item was closed in the meeting of 2004-04-02. It does not need to be done for 1.1, because it should be taken care of as an erratum to XML Schema 1.0 (see R-105). Cf. also RQ-16.

This item was classified as Req in the meeting of 2004-03-11.

This item was discussed, and phase-1 agreement was reached, in the meeting of 2004-04-02.

This item was discussed in the meeting of 2003-10-24

This item was discussed in the meeting of 2003-12-05

This item was discussed in the meeting of 2004-01-08

This item was discussed in the meeting of 2004-01-15

This item was discussed in the meeting of 2004-01-22

The WG formed task forces to prepare further work on this item in the meeting of 2004-02-27

This item was discussed in the meeting of 2004-03-18.

This item was discussed in the meeting of 2004-05-28.

This item was classified as Opp.Des. in the meeting of 2004-06-10.

This item was classified in the meeting of 2003-10-24

This item was discussed in the meeting of 2003-11-04

This item was discussed, and phase-1 agreement was reached, in the meeting of 2004-03-18.

This item was classified as a non-goal in the meeting of 2003-10-24

QT has asked to reclassify anyURI as subtype of string; all use cases are recasting to string anyway.

See member-only minutes http://www.w3.org/XML/Group/2003/07/xml-schema-ftf-minutes..

See also member-only mail http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0115.html.

This item was classified as a desideratum in the meeting of 2003-08-28

This item was discussed in the meeting of 2003-09-18. The consensus there was that we should not make anyURI a subtype of string, and that we should push back to QT against the behavior of Functions and Operators.

This item was discussed and then reclassified as a non-goal in the meeting of November 2003 in Redwood Shores.

At the meeting in Redwood Shores the XML Schema WG declined to make this change on the grounds that the semantics of anyURI are different from those of string.

R-22 says "The dataypes spec has some inconsistencies with IEEE with respect certain special values ...". It continues "Are +0 and -0 the same value?" Further, the F&O discusses both positive and negative zero as arguments to functions that accept float and double values. In some cases this is required by backwards compatibility with XPath 1.0 functions such as "round".

This item was mentioned in the meeting of 2003-09-18.

This item was discussed (and phase-1 agreement was reached) in the meeting of 2003-09-18.

This item was discussed in the meeting of 2003-10-16.

This item was discussed in the meeting of 2003-10-17.

This item was discussed in the meeting of 2003-11-21.

This item was discussed (editors noted that they had long ago proposed wording) in the meeting of 2004-04-29.

Should we add anyAtomicType as requested by QT? Should we add it as the supertype of all atomic types or as a union of all atomic types?

This item was discussed in the meeting of 2003-09-18

This item was discussed in the meeting of 2003-09-26

This item was discussed in the meeting of 2003-10-02

This item was discussed, and phase-1 agreement was reached, in the meeting of 2004-03-19.

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?

This item was discussed in the meeting of 2004-03-25. Three points were identified as close to consensus:

1 We should eliminate any dependency on the absence of specific properties (i.e. important situations should be describable and distinguishable in terms of properties and their values, without appeal to the absence of particular properties), or if this proves unfeasible in particular cases we should say explicitly that a property is present "if and only if" certain conditions apply. Any remaining "if" (if any) would be a true conditional, not an equivalence.

2 Any specification of a class of processors (including ours) can require specific additional information not in the PSVI, though should note that interoperability is better if applications depend only on the properties present in the PSVI as we define it.

3 In our own specification of processor classes, we should be explicit that processors may provide additional information. (Or alternatively be explicit that they must not -- but the chair believes the WG consensus was to allow it.)

This item was discussed in the meeting of 2004-04-01. Phase 1 agreement was reached on point 1 above. The other two points were moved to RQ-144.

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 mail: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0003.html

Discussed at the Sept. 20, 2003 concall.

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

[N.B. this candidate requirement was originally posed in the terms given by the email from Noah Mendelsohn cited below; it was amended on 25 March 2004 to read as follows:]

"[Definition:] Minimally conforming processors must completely and correctly implement the Schema Component Constraints, Validation Rules, and Schema Information Set Contributions contained in this specification."

Which at least appears to require that conforming processors report the PSVI. This would rule out, for example, processors that implement a simple validation check function such as:

     boolean IsValid(schema, instance) 

a function which is clearly useful in query languages, spreadsheets, and other systems that manage or access instance documents. Other interesting if somewhat less common reports might be to give only the type assignments of each element or attribute, etc. Even for validity, some applications will want details of validity down the entire tree, while others will want only the net result at the root. Interestingly, many applications will want the "value" from a simple type value space, which for some reason we have declined to include.

The range of useful processor APIs goes well beyond providing the full PSVI and only that. We should modify the spec in the light of that fact.

• There should be a clean separation between descriptions of the language(s) and descriptions of processors.
• We should make a good attempt to call out (in a separate chapter) a particular specification of processor classes that we hope will be useful and widely deployed.
• We should make clear that other processor class descriptions are OK; they are not to be thought of as second-class compared to ours.

See mail: from Noah Mendelsohn

This item was discussed in the meeting of 2004-03-11.

This item was discussed and amended in the meeting of 2004-03-25. The amended requirement was classified as Req.

This item was discussed in the meeting of 2004-04-01. We identified two points (originally formulated as part of RQ-142 but moved here by WG decision):

Any specification of a class of processors (including ours) can require specific additional information not in the PSVI, though should note that interoperability is better if applications depend only on the properties present in the PSVI as we define it.

In our own specification of processor classes, we should be explicit that processors may provide additional information. (Or alternatively be explicit that they must not -- but the chair believes the WG consensus was to allow it.)

Add a [value] property to the PSVI for attributes and for elements validated with simple content. This candidate requirement is facilitated by RQ-144, as we make clear that the [value] property need be computed only if needed.

With a [value] property, we can also suggest to Query that they augment the famously vague Data Model stipulation that:

"In the general case, dm:typed-value constructs a sequence of atomic values. These values are derived from the string-value of the element and its type, in such a way as to be consistent with validation."

Instead, or in addition one could put into their PSVI-to-DM mapping:

"string-value (unchanged)

The [schema normalized value] PSVI property if that exists, or the [normalized value] property.

typed-value (new)

The [value] PSVI property (reference to new PSVI property)

See mail: from Noah Mendelsohn

In its meeting of 2004-03-12, the Working Group decided (Henry Thompson dissenting) to classify this item as Non-goal.

This item was discussed in the meeting of 2004-05-13.

Consider the following "tricky" indirect case involving a wildcard referencing a global element:

<element name="a" type="string"/>
<complexType name="example-2">
  <sequence>
    <element name="a" type="int"/>
    <element name="whatever"/>
    <any namespace="##targetNamespace" processContents="lax"/>
  </sequence>
</complexType>

Clearly the local <a> and the indirect reference to the global <a> are "inconsistent" with each other within the content model of the above example but I'm not sure if the "directly, indirectly, or implicitly" language in the EDC rule captures this case.

See mail from: David Bau. See reply from: from Henry Thompson.

Proposals to discharge this requirement also cover RQ-17.

This item was classified as Req in the meeting of 2004-03-12.

This item was discussed in the meeting of 2004-04-09, in connection with RQ-17..

E2-35 makes the following declarations valid:

<simpleType name="st1">
  <restriction base="string">
    <length value="5"/>
  </restriction>
</simpleType>

<simpleType name="st2">
  <restriction base="st1">
    <minlength value="2"/>
  </restriction>
</simpleType> 

But the second derivation step doesn't seem to mean anything. This is analogous to having minInclusive=10 in the base and minExclusive=0 in the derived, which is not allowed by the spec.

It seems to be a good change to allow "length" after "min/maxLength", but not the other way around.

See mail from: Sandy Gao.

Ashok Malhotra replied that, perhaps for Schema 1.1, we should remove the length facet and make setting the length facet syntactic sugar for setting both maxLength and minLength to the same value. See: Ashok Malhotra.

This item was classified as nongoal in the meeting of 2004-04-08.

Phase out the length facet in favor of making length specifications in the schema document set the minLength and maxLength facets.

See also discussion of RQ-147 (non-goal).

See mail from: Sandy Gao.

This item was classified as desideratum in the meeting of 2004-04-08.

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 mail from: Steven Taschuk.

This is R-190. On the 11/21/2008 telcon we agreed to add to the 1.1 Requirements and classify as "Clarification without Erratum"

This item was discussed in the meeting of 2004-05-12.

Xan Gregg: Also known as "numeric exponents", when applied to model groups these cause inordinate complexity for subsumption testing on state machines generated from content models. Numeric exponents refer to occurrence constraints besides 0, 1, and unbounded (the values supported natively by regular expressions).

When asked, the WG members have been unable to point to a good use of such occurrence values. Henry Thomspon has noted in [1] that of the 700 schemas contributed by XSV users, there was only one non-trivial use of numeric exponents on a model group:

  <seq min=1 max=3>
   <elt min=0/>
   <elt min=0/>
   <elt min=0/>
  </seq>

For completeness, I have also noted one contrived case [2] that was found in a tutorial:

sandwich ::=
    lower_slice 
    [ mustard | mayonnaise ]
    lettuce? tomato?
    [ bologna | salami | ham ] {2,4}
    cheese+
    top_slice

The WG discussion broadened the scope of this issue to numeric exponents in general, not only for model groups.

[1]Henry Thompson

[2]J. David`Eisenberg

This item was discussed in the meeting of 2004-04-15.

This item was abandoned in the meeting of 2004-05-13.

John Tebbutt: Ashok Malhotra:

• If an implementation strictly implements a 18 digit decimal facility, it cannot accomodate long which requires 20 digits.

• 18 decimal digits cannot be accommodated in 64 bits.

This item was discussed in the meeting of 2003-12-19

This item was discussed in the meeting of 2003-12-18

This item was discussed in the meeting of 2003-10-31

This item was discussed in the meeting of 2003-10-30

This item was discussed in the meeting of 2003-11-04

This item was classified as requirement and discussed, and phase-1 agreement was reached, in the meeting of 2004-04-08.

This item was classified as Req in the meeting of 2004-06-10.

Should XML Schema 1.1 be aligned with XML 1.1? Some salient points on which XML 1.1 differs from XML 1.0 include:

• Documents may now be labeled <?xml version="1.1">. Such a designation MAY be used, but is discouraged, if the document could also have been serialized as <?xml version="1.0">; the new designation is required, of course, when new features described below are used.
• The set of name characters for element and attribute names has been expanded, and indeed is now open-ended: XML 1.1 allows such names to include not just current Unicode characters, but others that may be assigned by the Unicode consortium in the future. As I understand it, the distinction between the evolving flavors is not signaled in the XML declaration. Version="1.1" allows any possible future characters, but only if the Unicode consortium has assigned them.
• The definition of "char" has been changed to allow previously disallowed control characters in the range #x1 through #x1f.
• Some new line end characters have been introduced. These are handled quite early in XML processing, and may not cause schema much trouble because they won't be visible at the Infoset level where Schema works.

Several points on which alignment may be needed have been identified; in the words of Henry Thompson (first item) and Noah Mendelsohn (others):

1. XML 1.1 adds #x85 and #x2028 to the characters involved in line break normalization. XML Schema may need to change our whitespace handling in 1.1 to take account of this.
2. We use Infosets for instances and schemas. There is a question as to how one knows whether the new names and content might appear in such an Infoset. It may be implied that the switch is to be found in the [version] property of the document information item. Concerns regarding the Infoset include:
   • While the version property is indeed in the Infoset rec, and the 2nd addition talks about needing a processor that can handle whatever serialized document you might have, I don't think it specifically ties the legal values of properties such as the [local name] of an element or legal [character codes] to this [version] property. Synthetic Infosets, for example, need to be covered IMO. For example, the newly published Infoset Rec says "[character code] The ISO 10646 character code (in the range 0 to #x10FFFF, though not every value in this range is a legal XML character code) of the character.", which seems a bit vague on what it means to be an XML character.
   • We in schemas define both schema "documents" and instances to be validated as element information items, with no reference to a required or containing document information item. I think we need to consider whether the [version] property of the doc info item would meet our need to determine what version of XML we've got with respect to instances and (purported) schema documents.
3. Our xsd:string type explicitly refers to the char production of XML 1.0 2nd addition. Thus, it will not validate strings containing the control characters of XML 1.1. We could perhaps introduce a new type that would validate the new content, but there are complications, including:
   • xsd:string is base for types like xsd:token, so we might have to create parallel versions of some of those
   • If you wanted to write a schema document that had an enumeration or fixed value constraint containing the new characters, then that schema document would have to be expressed as an XML 1.1 Infoset (see comment above regarding possible ambiguity about which Infosets are 1.1)
   • Our pattern language is designed to constrain strings, but as I read the spec it defines "A normal character is any XML character that is not a metacharacter." With the publication of XML 1.1 we see in hindsight that this is insufficiently precise.
4. Since the range of legal element names has changed, we face questions regarding our ability to validate element and attribute content using the new names.
   • If your schema is written as a schema document, then presumably you can only enter the names if the document is an XML 1.1 Infoset (similar to concern raised for enumerations on strings)
   • Since the range is implicitly extensible as Unicode changes, it would seem that even a label of XML 1.1 on an infoset for a schema document does not ensure that it has the expressive power to name all the XML element and attribute names that one might wish to validate. Some processor might be checking the schema document with knowledge of, say Unicode 4.0, but the schema document might have been written with knowledge of a Unicode 5.0 that "assigned" no characters.
   • We have types such as xsd:name about which our Recommendation says "[Definition:] Name represents XML Names. The value space of Name is the set of all strings which match the Name production of [XML 1.0 (Second Edition)]. The lexical space of Name is the set of all strings which match the Name production of [XML 1.0 (Second Edition)]. The base type of Name is token. " Note that xsd:token is derived from xsd:string, which is discussed above.
   • We have an xsd:Qname type, the definition of which is "[Definition:] QName represents XML qualified names. The value space of QName is the set of tuples {namespace name, local part}, where namespace name is an anyURI and local part is an NCName. The lexical space of QName is the set of strings that match the QName production of [Namespaces in XML]." That link to [Namespaces in XML] is explicitly to: "World Wide Web Consortium. Namespaces in XML. Available at: http://www.w3.org/TR/1999/REC-xml-names-19990114/", which is to the 1999 Namespaces in XML recommendation.
   • We use that QName type in the schema for schemas for the names of elements and attributes to be validated, as well as for references within schemas.
   • Our component descriptions tend to have {name} properties that constrain their content by that same 1999 version of Namespaces. See for example the element declaration schema component. In general, there is a necessary tie between what we can put in these component properties, what we can express in a serialized schema document, what we can express in the corresponding schema document infoset, what's allowed by the xsd:Qname type, and the names of elements and attributes we can validate.
5. Our type system is used by others such as query, both in the data model and as the type system for functions and operators. As we wrestle with the definitions of types like xsd:string and xsd:name, I presume that some intensive liaison with them will be needed. It's not implausible that if we introduce an xsd:stringv11 type, that duplicate functions would be needed for every F&O function that accepts or returns a string. Likewise for xsd:Qname, etc. Other groups such as XMLP and RDF also use our type system and might be affected by changes or by lack of synergy with XML 1.0 or XML 1.1.
6. We talk about the representation of XML schema documents for retrieval on the web. The pertinent part of the description of the web resource to be retrieved says: "It resolves to (a fragment of) a resource which is an XML document (of type application/xml or text/xml with an XML declaration for preference, but this is not required), which in turn corresponds to a <schema> element information item in a well-formed information set, which in turn corresponds to a valid schema." It seems we now need to be clearer as to if and when such documents may have <?xml version="1.1"?>, what the rules are for cross-importing and including across versions, etc. All of these must be related to whatever we decide above regarding rules for our components, types, enumeration constraints, etc.

See note to comments list on 6 February 2004 from Henry Thompson.

See note to comments list on 19 February 2004 from Noah Mendelsohn.

See also proposed erratum for XML Schema 1.0 sent on 8 June 2004 by C. M. Sperberg-McQueen (and ensuing discussion).

The XML Schema 1.1 specification must choose either to use the same namespace as 1.0, or to use a different namespace, or to use more than one namespace. An explicit decision should be made.

In our general outline of compatibility goals for 1.1, the WG agreed that we would avoid changes to the XML transfer syntax, in order that XML Schema 1.0 processors can successfully process 1.1 schema documents. This seems to some to entail making no change in the namespace.

At the same time, we also agreed that changes to the XML transfer syntax might be made nevertheless, if they were necessary in order to support versioning better. This seems to some to imply that any final decision on whether we will make breaking changes is still out; if we do, some WG members will wish to entertain the possibility of changing the namespace, or adding additional namespaces.

This topic was raised in the Working Group call of 1 July 2004, and it was agreed to create a separate requirement to make it easier to track.