W3C XML Schema 1.1: Pre-Last Call Issues

Inside: Issue summary | State description | Decision cycle description | Issue details (Validate data)

Editors: Asir S. Vedamuthu, webMethods and Mary Holstege, Mark Logic, Inc.

Until this document was closed (September 2005), it was the official pre-Last Call issues list for XML Schema 1.1 working drafts.

Status of this Document

Note, 8 September 2005: This document has been closed 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 it among the Bugzilla entries for XML Schema.

This document contains a list of issues regarding the XML Schema 1.1 Part 1 and Part 2 working drafts raised before August 2005. All comments or issues regarding the specification or this document should be reported using Bugzilla; if you prefer not to use Bugzilla, issues may instead be reported by email to www-xml-schema-comments@w3.org (public archives).

An XML version of this issues list is also available.

Issue summary (34 issues)

Reformat summary with options:
Expert mode options
Hide columns:
Hide issues by type:
Hide issues by state:
Hide issues by acknowledgment:

Other views: types | states | concerning | reviewers | open actions

Changes between dates (YYYY-MM-DD) and [Optional]

For maintainers: new issue data | new issues list data

Color key: error warning note

Id: TitleStateTypeOpen actionsAck.
wd-23 : Misleading - Schema Component Constraint: applicable facetsno decision
(raised)
editorial
wd-27 : Errors in component diagramno decision
(raised)
editorial
wd-30 : Fundamental facet table is messed upno decision
(raised)
editorial
wd-31 : 1.1 working draft and unicodeno decision
(raised)
editorial
wd-4 : Confusing description of equalityagreededitorial
  1. Part 2 Editors
No response to reviewer
wd-5 : Editorial commentsagreededitorial
  1. Part 2 Editors
No response to reviewer
wd-14 : Editorial note on section 5.2agreededitorial
  1. Part 1 Editors
Agreement
wd-17 : Suggested replacement text for 3.2.7.1agreededitorialNo response to reviewer
wd-6 : Summary of Changessubsumededitorial
wd-1 : "constructed from ID" vs. "derived from ID" in Structuresno decision
(raised)
error
wd-22 : Applying default values of type QName (and NOTATION)no decision
(raised)
error
wd-3 : Confusing description of identity, specifically a warning in section 2.2.2agreederror
  1. Part 2 Editors
No response to reviewer
wd-7 : error in timeOnTimeline functionagreederror
  1. Part 2 Editors
No response to reviewer
wd-11 : Incorrect definition of the {facets} propertyagreederror
  1. Part 2 Editors
No response to reviewer
wd-2 : "fixed value constraint" based on identity or equalityagreederror
  1. Part 2 Editors
Agreement
wd-21 : Canonical representation of QName/NOTATION valuesagreederror
  1. Part 2 Editors
Agreement
wd-26 : When did timezones cease being durations?agreederror
  1. Part 2 Editors
Agreement
wd-9 : Error in derived-from-duration regexessubsumederror
wd-10 : Error in setDateTimeFromRaw proceduresubsumederror
wd-15 : gDay and setDateTimeFromRaw edge casesubsumederror
wd-16 : gDay and timeOnTimeLine edge casesubsumederror
wd-18 : Duplicate normative parts in Part 1 (3.14) and 2 (4.1)no decision
(raised)
proposal
wd-24 : Regarding upper and lower bounds (another problem with paternalism)no decision
(raised)
proposal
wd-25 : anyURI, RFCs 2396 and 3896no decision
(raised)
proposal
wd-28 : Proposal from the i18n-core wg for changes of anyURIno decision
(raised)
proposal
wd-29 : URI changes in RFC 3986no decision
(raised)
proposal
wd-19 : base64 and linefeedsagreedproposal
  1. Part 2 Editors
Agreement
wd-13 : Underspecification in fallback to lax processingagreedrequest
  1. Part 1 Editors
No response to reviewer
wd-34 : What are the rules for list equality?agreedrequest
  1. Part 2 Editors
No response to reviewer
wd-33 : Are lexical maps functions or relations?agreedrequest
  1. Part 2 Editors
Agreement
wd-8 : Do not change anything that affects our code, unless something importantdeclinedrequestAgreement
wd-20 : Identity vs. Equality in enumerations and fixed value constraintsdeclinedrequestAgreement
wd-32 : How do we calculate the value of a facet?declinedrequestAgreement
wd-12 : Content Model for Attributessubsumedrequest

State description

Decision cycle description

Issue details

wd-23: Misleading - Schema Component Constraint: applicable facets [link to this issue]

in part 2 is at best misleading wrt lists and unions -- their {base type definition} cannot be any datatype, as is implied by the table, rather for unions is aST or another union, for lists its aST or another list.

Editorial concerning

Transition history

raised on 7 Jan 2005 by Henry S. Thompson (ht@inf.ed.ac.uk)

wd-27: Errors in component diagram [link to this issue]

The component model diagram in appendix I of http://www.w3.org/TR/2005/WD-xmlschema11-1-20050224/ needs some corrections, including but not limited to. * Should be an arc from the schema component to identity constraints * substitution group affiliation should be a circular arc * facets are components; should be arcs * don't understand why the arc from the schema component to complex type definitions is dotted

Editorial concerning

Transition history

raised on 25 Mar 2005 by Mary Holstege

wd-30: Fundamental facet table is messed up [link to this issue]

3. Fundamental facet table

Something's wrong with the table in Appendix F.1:
- The "primitive" cell is missing and the "non-primitive" cell is moved up
- The 2 new duration types are not in the table
Editorial concerning

Transition history

raised on 14 Apr 2005 by Sandy Gao

wd-31: 1.1 working draft and unicode [link to this issue]

The reference to unicode [1] in the schema 1.1 part 2 working draft [2] 
doesn't point to the latest version of the unicode database.

[1] http://www.unicode.org/Public/3.1-Update/UnicodeCharacterDatabase-3.1.0.html
[2] http://www.w3.org/TR/xmlschema-2/
Editorial concerning
Part 2

Transition history

raised on 11 May 2005 by Sandy Gao

wd-4: Confusing description of equality [link to this issue]

In 2.2.2

"On the other hand, equality need not cover the entire value space of the datatype (though it usually does)."

Not sure what this sentence is trying to say. That some value in some value space is never equal to any other values?

Editorial concerning
Part 2

Transition history

raised on 25 Jun 2004 by Sandy Gao
agreed on 19 Nov 2004

Assign to editors to fix

Acknowledgment cycle
Not started

Action history

Part 2 Editors

wd-5: Editorial comments [link to this issue]

I don't see the value of pointing out that equality is a congruence relation. The only other occurrence of "congruence" is in the appendices that define it.

I don't see what the first occurrence of "on the other hand" is referring to as the first hand.

as in the Order section, we should define the '=' notation before using it instead of the other way around.

I think you explained it, but I still find confusing, "there is one equality relation for all values of all datatypes"

Editorial concerning
Part 2

Transition history

raised on 7 Apr 2004 by Xan Gregg
agreed on 19 Nov 2004

Assign to editors to fix

Acknowledgment cycle
Not started

Action history

Part 2 Editors

wd-14: Editorial note on section 5.2 [link to this issue]

There is a grammatical oddity (as well as a certain amount of obscurity) in a sentence in section 5.2 of Structures.

I believe the sentence

3 The processor starts from Schema-Validity Assessment (Element) (3.3.4) with no stipulated declaration or definition, and either strict or lax assessment ensues, depending on whether or not the element information and the schema determine either an element declaration (by name) or a type definition (via xsi:type) or not.

has one 'or not' too many.

Quick fix: delete the first 'or not', yielding

3 The processor starts from Schema-Validity Assessment (Element) (3.3.4) with no stipulated declaration or definition, and either strict or lax assessment ensues, depending on whether the element information and the schema determine either an element declaration (by name) or a type definition (via xsi:type) or not.

This has the drawback that it makes the decision about strict or lax assessment easier to misunderstand than it was before.

I believe that what is meant is

3 The processor starts from Schema-Validity Assessment (Element) (3.3.4) with no stipulated declaration or definition. If the element information and the schema determine either an element declaration (by name) or a type definition (via xsi:type), then strict assessment is performed; otherwise, the element information item is validated with respect to the ur-type definition.

If my understanding is correct, I offer the wording just above as a possible rewording of the rule.

If my understanding is incorrect, I offer the wording just above as evidence of one way that a reasonably attentive reader can be led astray by the current wording.

Editorial concerning

Transition history

raised on 2 Nov 2004 by C. M. Sperberg-McQueen
agreed on 10 Dec 2004

RESOLVED: to close issue wd-14 by accepting the second proposed wording.

Acknowledgment cycle
announced by group on 10 Dec 2004
agreement by reviewer on 10 Dec 2004

Action history

Part 1 Editors
  • accepted on 10 Dec 2004

    Editors to adjust wording of the editorial note in section 5.2 of part 1 (the bit commented in in issue wd-14), using the second proposed wording.

wd-17: Suggested replacement text for 3.2.7.1 [link to this issue]

I think the first part of section 3.2.7.1 in the datatypes draft can be shortened as suggested below. This concerns the value space of the duration datatype.

I suggest that first paragraph of the 3.2.7.1 and the following box be replaced by the text below.

"Duration values can be modelled as two-property tuples. Each value consists of an integer number of months followed by a decimal number of seconds. The seconds value MUST not be negative of the months value is positive and MUST not be positive if the months value is negative."

Editorial concerning

Transition history

raised on 27 Aug 2004 by Ashok Malhotra
agreed on 19 Nov 2004

RESOLVED: Ashok's recommendation approved as amended (leave the box alone)

Acknowledgment cycle
announced by group on 19 Nov 2004
agreement by reviewer on 19 Nov 2004
agreed on 29 Apr 2005

DE had a comment on the locution "the second property" which is misleading. MSM suggested changing properties in duration values to plural to avoid that problem. Shouldn't be hard, they are autogenerated.

NM had a suggested change as well (http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2005Apr/0060.html): "duration is partially ordered. Equality of duration is defined in terms of equality of dateTime; order for duration is defined in terms of the order of dateTime. Specifically, the equality or order of two durations is determined by adding each duration in the pair to each of the following four dateTimes:"

RESOLVED: Dispose of RQ-17 by accepting proposal http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2005Apr/att-0059/wd-17.html__charset_ISO-8859-1 as amended to change property names and with paragraph on partial order above.

Acknowledgment cycle
Not started

Action history

Part 2 Editors

wd-6: Summary of Changes [link to this issue]

My only substantive comment applies to both Part 1 and Part 2. I think it would really help readers to provide a summary of changes, both substantive, such as changes to {scope}, and editorial, such as micro-components. Otherwise, some reviewers will not notice them, and we will miss their comments.

Editorial concerning

Transition history

raised on 27 Jun 2004 by Xan Gregg
Subsumed by issue(s) on 19 Nov 2004

Subsumed by the summary of changes section in the first public working drafts

wd-1: "constructed from ID" vs. "derived from ID" in Structures [link to this issue]

I noticed that many occurrences of "derived from ID" (similarly IDREF/IDREFS) are replaced with "constructed from ID". Is this a conscious decision we have made?

In 1.0, only those types that are derived from ID/IDREF/IDREFS by restriction are considered ID/IDREF/IDREFS types. If we use "constructed" instead, it means that lists and unions of these types are also treated specially. Don't remember we've made a decision here. Maybe I missed something.

As section 2.2.1.1 mentions, one of 2 entities is used to replace the old "derived". Shouldn't the &derived; one be used instead of the &constructed; one for these cases?

Error concerning
Part 1

Transition history

raised on 25 Jun 2004 by Sandy Gao

wd-22: Applying default values of type QName (and NOTATION) [link to this issue]

When a default/fixed attribute/element value is of type QName/NOTATION, 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.)

Error concerning
Discussion history
12 Dec 2000, 17 Jan 2001, 2 Mar 2001, 6 May 2005

Transition history

raised on 8 Dec 2004 by Sandy Gao

wd-3: Confusing description of identity, specifically a warning in section 2.2.2 [link to this issue]

Right above section 2.2.2

"WARNING: Care must be taken when identifying values across distinct primitive datatypes. It turns out that, for example, 0.1 and 0.10000000009 are effectively identical in float but not in decimal. (Neither 0.1 nor 0.10000000009 are in the float value space, but ·the lexical mapping· of float maps both '0.1' and '0.10000000009' to the same number (0.100000001490116119384765625) that is in the float value space.)"

I can understand what this paragraph is trying to say, but the sentence "0.1 and 0.10000000009 are effectively identical in float" might be a bit confusing. We don't seem to be talking about the value space, because neither is in the value space of float; we don't seem to be talking about the lexical space either, because we didn't use quotes around the values.

Error concerning
Part 2

Transition history

raised on 25 Jun 2004 by Sandy Gao
agreed on 19 Nov 2004

Assign to editors to fix

Acknowledgment cycle
Not started

Action history

Part 2 Editors

wd-7: error in timeOnTimeline function [link to this issue]

The timeOnTimeline function doesn't behave correctly for date/time datatypes having forced-absent properties.

Specifically, what should happen is that the first six values (always stored normalized to Z) should be denormalized to their local values (previously called "raw" values), then the default values applied to the absent ones, and finally the result renormalized to Z and the calculation completed. Mea culpa.

N.B.: This may also be a problem with some other date/time functions; I'll check at some point.

Error concerning

Transition history

raised on 29 Jul 2004 by Dave Peterson
agreed on 15 Apr 2005

Acknowledgment cycle
Not started

Action history

Part 2 Editors

wd-11: Incorrect definition of the {facets} property [link to this issue]

It appears that the definition of the {facets} property of the simple type definition schema component includes both the fundamental and constraining facets, according to the definition. OTOH, since the description talks about a possibly empty set of facets and there is also a {fundamental facets} property which is the set of fundamental facets, I suspect it was intended that the {facets} property only include constraining facets.

Error concerning

Transition history

raised on 19 Sep 2004 by Dave Peterson
agreed on 3 Dec 2004

RESOLVED Accepts DaveP's resolution of wd-11 (that is, to make {facets} not include fundamental facets) if there is no objection from Sandy's review (See 2004-12-03 action to Sandy).

Acknowledgment cycle
Not started

Action history

Sandy Gao
  • accepted on 3 Dec 2004

    Sandy to report to the WG by 2004-12-10 if there is any objection or need for further discussion on wd- 11. (2004-12-03)

  • completed on 8 Dec 2004

    It's always been our interpretation that the {facets} property of simple type definitions was only intended to contain "constraining facets". (Though not normative, 3.14.1 in part 1 does mention "A set of constraining facets" explicitly.) So the change implied by wd-11 sounds good to us.

Part 2 Editors

wd-2: "fixed value constraint" based on identity or equality [link to this issue]

2.2 mentions that identity is *only* used for enumeration and identity constraints; and equality is *only* used in conjunction with order (presumably when checking the range facets).

But I suppose "fixed value constraint" also needs to use one of these 2 relations. Did we make a decision?

Error concerning
Part 1

Transition history

raised on 25 Jun 2004 by Sandy Gao
agreed on 3 Dec 2004

RESOLVED Close wd-2 by instructing the editors to treat fixed value constraints the same as enumeration with regards to identity vs equality.

Acknowledgment cycle
announced by group on 3 Dec 2004
agreement by reviewer on 3 Dec 2004

Action history

Part 2 Editors
  • accepted on 3 Dec 2004

    Editors to treat fixed value constraints the same as enumeration with regards to identity vs equality.

wd-21: Canonical representation of QName/NOTATION values [link to this issue]

The lexical representation of a QName/NOTATION value has the form "prefix:localpart" (or "localpart"), and the value of a QName is a tuple {namespace, localpart}. Then what's the canonical representation of a QName/NOTATION value? How is the prefix (if any) picked? How is it guaranteed that the prefix is always bound to the desired namespace?

Error concerning

Transition history

raised on 8 Dec 2004 by Sandy Gao
agreed on 29 Apr 2005

Decided to add a health warning about canonical forms.

Acknowledgment cycle
announced by group on 29 Apr 2005
agreement by reviewer on 29 Apr 2005

Action history

Part 2 Editors

wd-26: When did timezones cease being durations? [link to this issue]

With some dismay, I discovered this morning that the treatment of the seven-property time model in our status-quo document describes the timezone component as as integer (representing a number of minutes).

This is a change from 1.0, which describes timezones as durations, and it conflicts with the treatment of timezones in the QT data model. (Since normalization and denormalization involve addition and subtraction of timezones to dateTime values, treating timezones as integers would lead to some inconvenience for F and O.)

Perhaps I was asleep at the switch at the moment when we discussed this, in which case I apologize to the Working Group and anyone else concerned for failing to raise this issue then. But I think this is an important, though small, issue.

I propose that as a matter of some urgency the WG ask the editors to prepare a wording proposal changing timezones back to being durations.

Error concerning

Transition history

raised on 1 Mar 2005 by C. M. Sperberg-McQueen
agreed on 19 May 2005

RESOLVED Close wd-16 by instructing editors to reintroduce the word 'duration', but not the claim that it is an instance of xs:duration.

Acknowledgment cycle
announced by group on 19 May 2005
agreement by reviewer on 19 May 2005

Action history

Part 2 Editors

wd-9: Error in derived-from-duration regexes [link to this issue]

Ashok has caused me to look closely at the regex given in the text of each derived-from-duration datatype, and I find that I forgot to escape the '-' and '.' characters. They should be escaped:

\-?P([0-9]+D)?(T([0-9]+H)?([0-9]+M)?([0-9]+(\.[0-9]+)?S)?)? \-?P([0-9]+Y)?([0-9]+M)? for dayTimeDuration and yearMonthDuration respectively.

Error concerning

Transition history

raised on 7 Sep 2004 by Dave Peterson
Subsumed by issue(s) on 15 Apr 2005

wd-9 subsumed by rq-20

wd-10: Error in setDateTimeFromRaw procedure [link to this issue]

There is an error in the initialization algorithm for the local variable mi in the setDateTimeFromRaw procedure:

>Let yr be rawYear when rawYear is not absent, dt's year when dt's

> year is not absent but rawYear is, and 1971 otherwise,

>mi be rawMi, dt's minute , or 0, similarly

Since the object is to set the variable to a "raw" ("local timezone") value, the defaults (which are normalized-to-Z values) should be offset by the timezone:

mi be rawMi, (dt's minute + dt's timezone, or dt's timezone) when dt's timezone is not absent, and (dt's minute, or 0) otherwise, similarly

This insures that subtracting the timzone later will restore the default Z value. Of course, the wording can no doubt be improved. Other formulations could be made that would preclude the necessity of adding then subtracting the timezone value, since the net result of the algorithm when the timezone is absent is just to normalize the values and set the time.

N.B.: Depending on the intended use, it might be necessary to use lssNormalizeSecond rather than normalizeMinute, and such a change would never hurt, so should also be made.

Error concerning

Transition history

raised on 8 Sep 2004 by Dave Peterson
Subsumed by issue(s) on 22 Apr 2005

DaveP reported that this was resolved by virtue of our decision to store values in local form, rather than in Z.

wd-15: gDay and setDateTimeFromRaw edge case [link to this issue]

Lexical mapping

Consider the following 2 lexical values for type gDay:

"---01+01" "---31+01"

In the function "setDateTimeFromRaw", rawYr, rawMo, rawHr, rawMi and rawSe are all absent, and the defaults are used. Before applying the timezone, we have

{1971, 12, 1, 0, 0, 0} and {1971, 12, 31, 0, 0, 0}

for the 2 lexical values respectively. After applying the timezone (subtract 60 from the minute field and normalize), we have

{1971, 11, 30, 23, 0, 0} and {1971, 12, 30, 23, 0, 0}

and the last step in "setDateTimeFromRaw" is to ignore those fields that were absent. Now we have (including the timezone):

{absent, absent, 30, absent, absent, absent, 60} and {absent, absent, 30, absent, absent, absent, 60}

So the 2 obvious different lexical values give rise to the same value in the value space.

Error concerning

Transition history

raised on 5 Nov 2004 by Sandy Gao
Subsumed by issue(s) on 22 Apr 2005

Sandy Gao and DaveP agreed that this is overtaken (or resolved) by our decision to store local values.

wd-16: gDay and timeOnTimeLine edge case [link to this issue]

Ordering

The following example is shown in the gDay type:

---01+13:00 < ---31?13:00

from which I assume the following is true (required by RQ-13)

---01+01:00 < ---10+01:00

But:

- Order and equality are based on the timeOnTimeLine values;

- timeOnTimeLine values are based on the (normalized) time values;

- time values don't have year, month and date properties

{absent, absent, 30, absent, absent, absent, 60} > {absent, absent, 9, absent, absent, absent, 60}

where the first value maps to "---01+01:00", and the second "---10+01:00", so we have

---01+01:00 > ---10+01:00

Error concerning

Transition history

raised on 5 Nov 2004 by Sandy Gao
Subsumed by issue(s) on 22 Apr 2005

Sandy Gao and DaveP agreed that this is overtaken (or resolved) by our decision to store local values.

wd-18: Duplicate normative parts in Part 1 (3.14) and 2 (4.1) [link to this issue]

Both in 1.0 2E and 1.1 (both FPWD and our current internal drafts) there is an overlap of both subject matter and prose between these two sections. Furthermore, some of the duplicated prose is implicitly normative in both Parts.

We should do a careful survey of this, and make sure that the disposition between the two Parts is optimal.

Proposal concerning

Transition history

raised on 8 Nov 2004 by Henry S. Thompson (ht@inf.ed.ac.uk)

wd-24: Regarding upper and lower bounds (another problem with paternalism) [link to this issue]

The definition of maxInclusive defines a constraint on schemas that says:

Schema Component Constraint: maxInclusive valid restriction

It is an error if any of the following conditions is true:

1 maxInclusive is among the members of {facets} of {base type definition} and {value} is greater than the {value} of that maxInclusive.

2 maxExclusive is among the members of {facets} of {base type definition} and {value} is greater than or equal to the {value} of that maxExclusive.

3 minInclusive is among the members of {facets} of {base type definition} and {value} is less than the {value} of that minInclusive.

4 minExclusive is among the members of {facets} of {base type definition} and {value} is less than or equal to the {value} of that minExclusive.

This suggests that incompatible or nonsensical values for upper and lower bounds are illegal, but only if imposed in different steps. Does that mean that it's legal to write the following?

<xsd:simpleType> <xsd:restriction base="xsd:integer"> <xsd:maxInclusive value="10"/> <xsd:maxExclusive value="10"/> </xsd:restriction> </xsd:simpleType>

Or have I missed some rule elsewhere?

I take this as another instantiation of the principle that a paternalist's work is never done, and that life will be simpler and we will have more confidence in the correctness of our spec if we abandon paternalism.

Proposal concerning
Discussion history
27 Jan 2005

Transition history

raised on 27 Jan 2005 by C. M. Sperberg-McQueen

wd-25: anyURI, RFCs 2396 and 3896 [link to this issue]

RFC 2396 (the URI spec) has now been obsolted by RFC 3896 [1,2]. Any chance of updating the references in xs:anyURI to 3896 before the next WD is published? AFAIK, no changes in xs:anyURI are necessitated by the change. pvb

[1] http://www.ietf.org/rfc/rfc3986.txt

[2] http://lists.w3.org/Archives/Public/www-tag/2005Jan/0022.html

Proposal concerning
Discussion history
18 Feb 2005, 18 Feb 2005, 19 Feb 2005, 19 May 2005

Transition history

raised on 18 Feb 2005 by Biron,Paul V (Paul.V.Biron@kp.org)

wd-28: Proposal from the i18n-core wg for changes of anyURI [link to this issue]

This is a proposals for changes of the datatype anyURI, as described by xml schema (cf. http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#anyURI). It is send on behalf of the i18n-core wg.

The i18n-core-wg proposes an update of the datatype anyURI which is defined in the current version of XML Schema part 2, cf. http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#anyURI Currently the mapping from anyURI values to URIs is defined in terms of the XLINK specification, cf. http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators . We think that anyURI should refer to the specification of Internationalized Resource Identifiers (IRIs) instead, cf. http://www.ietf.org/rfc/rfc3987. The IRI specification has achieved a stable status. It is a specification of how to expand the set of characters in URIs from a subset of US-ASCII to the Universal Character Set (Unicode/ISO 10646). W3C has announced to support the IRI specification, so we propose its application for anyURI. Our proposal for anyURI consists of 4 points:

(1) anyURI should refer to sec. 3.1 of the IRI-spec, instead of XLINK. This is important for example because of the normalization requirements as described in the IRI specification: if a legacy-encoding is not normalized before mapping from anyURI to URIs, the result might be different from the normalized case. The IRI specification gives an example for such a legacy-encoding from Vietnamese encoded as windows-1258, cf. also sec. 3.1. The normalization problem is only an example of many other important details which are discussed in the IRI specification.

(2) Any reference to URI should be updated from RFC 2396 to RFC 3987. For domain names, anyURI should refer to the IDN-part of the ABNF of the IRI-spec, cf. sec. 2.2 of the IRI-spec. This will allow access to internationalized domain names.

(3) The definition of anyURI may want to point to the following paragraph from section 3.1 of the IRI specification: "Systems accepting IRIs MAY also deal with the printable characters in US-ASCII that are not allowed in URIs, namely "<", ">", '"', space, "{", "}", "|", "\", "^", and "`", in step 2 above. If these characters are found but are not converted, then the conversion SHOULD fail. Please note that the number sign ("#"), the percent sign ("%"), and the square bracket characters ("[", "]") are not part of the above list and MUST NOT be converted. Protocols and formats that have used earlier definitions of IRIs including these characters MAY require percent-encoding of these characters as a preprocessing step to extract the actual IRI from a given field. This preprocessing MAY also be used by applications allowing the user to enter an IRI."

(4) an editorial issue: the reference from anyURI to section 8 of the old version of the "character model for the world wide web" specification should be changed to the new charmod-resid specification, cf. http://www.w3.org/TR/2004/CR-charmod-resid-20041122/

Proposal concerning

Transition history

raised on 4 Apr 2005 by fsasaki@w3.org, on behalf of I18N Core WG

wd-29: URI changes in RFC 3986 [link to this issue]

I would ask that the schema working group decide how or whether to upgrade the anyURI data type in schemas 1.1 to support the new syntax of RFC 3986. It's mostly but not quite the same as the older syntax in RFC 2396. For instance RFC 2396 allows an indefinite number of colons and @ signs in registry names, while 3986 does not. For instance, this URI is legal according to 2396 but not 3986:

dcp.tcp.pft://192.168.0.1:1002:3002?fec=1&crc=0

This has recently been raised as an issue in Xerces-J's schema validation. See

http://issues.apache.org/jira/browse/XERCESJ-1060

There may be other incompatibilities as well.

Proposal concerning

Transition history

raised on 9 Apr 2005 by Elliotte Rusty Harold

wd-19: base64 and linefeeds [link to this issue]

RFC 3548 is better reference than RFC 2045 (MIME) for defining Base64 in XML Schema Part 2. Future versions, at least, should use the newer document as a reference. The good news is that XML Schema's departure from RFC 2045 regarding linefeeds and whitespace (disallowing them in the canonical representation) is in agreement with RFC 3548:

2.1. Line feeds in encoded data

MIME is often used as a reference for base 64 encoding. However, MIME does not define "base 64" per se, but rather a "base 64 Content-Transfer-Encoding" for use within MIME. As such, MIME enforces a limit on line length of base 64 encoded data to 76 characters. MIME inherits the encoding from PEM stating it is "virtually identical", however PEM uses a line length of 64 characters. The MIME and PEM limits are both due to limits within SMTP.

Implementations MUST NOT not add line feeds to base encoded data unless the specification referring to this document explicitly directs base encoders to add line feeds after a specific number of characters.

Proposal concerning

Transition history

raised on 24 Nov 2004 by Xan Gregg
agreed on 22 Apr 2005

MSM proposed that we agree with the comment; no dissent.

Acknowledgment cycle
announced by group on 22 Apr 2004
agreement by reviewer on 22 Apr 2004

Action history

Part 2 Editors
  • accepted on 22 Apr 2005

    DT editors to check that RFC 3548 is (still) the latest, and update references in Datatypes to point to latest RFC, thus resolving wd-19. (Result will take the form of an Editorial Proposal.)

wd-13: Underspecification in fallback to lax processing [link to this issue]

As recently pointed out in an exchange between Sandy Gao and Henry Thompson on the IG list (under the subject heading "Validation rules for children of skipped elements"), the paragraph at the end of Schema-Validity Assessment (Element) is slightly underspecified. It says:

If the item cannot be strictly assessed, because neither clause 1.1 nor clause 1.2 above are satisfied, [Definition:] an element information item's schema validity may be laxly assessed _if its context-determined declaration is not skip_ by validating with respect to the ur-type definition as per Element Locally Valid (Type)

[emphasis added by HT]

The spec does not say whether validation with respect to the ur-type definition is allowed if the item's context-determined declaration IS skip, or not.

The spec also does not call out this and other implementation-dependent behaviors; it should.

Request concerning

Transition history

raised on 28 Oct 2004 by C. M. Sperberg-McQueen
accepted on 17 Dec 2004
Background, proposals, threads, notes

RESOLVED: Classify issue wd-13 as "accepted"

_This_ issue stems from SG's challenge to prove that if have an element which matches a skip wildcard and it has a child that would be invalid against declaration, then I am not allowed to fallback to lax validation for children of skip wildcard. SG's point is the spec is underspecified and we need to make it clear: "you may do this under the following circumstances _and only_ under those circumstances" Suggest we should therefore "accept" this as an issue.

agreed on 22 Apr 2005

We have a resolution

Acknowledgment cycle
Not started

Action history

Part 1 Editors

wd-34: What are the rules for list equality? [link to this issue]

R-181
Request concerning
Part 2

Transition history

raised on 18 May 2005 by Stefan Wachter
agreed on 19 May 2005

Datatype editor to resolve R-181 by defining identity and equality of lists in terms of pairwise member identity and equality, respectively.

Acknowledgment cycle
Not started

Action history

Part 2 Editors
  • accepted on 19 May 2005

    DT editors to prepare an editorial proposal to resolve wd-34 by defining identity and equality of lists in terms of pairwise member identity and equality, respectively.

wd-33: Are lexical maps functions or relations? [link to this issue]

Request concerning
Part 2

Transition history

raised on 18 May 2005 by Henry S. Thompson (ht@inf.ed.ac.uk), on behalf of Schema WG
agreed on 19 May 2005

Awaiting proposal from the editors.

Acknowledgment cycle
announced by group on 19 May 2005
agreement by reviewer on 19 May 2005

Action history

Part 2 Editors

wd-8: Do not change anything that affects our code, unless something important [link to this issue]

It is a mistake for us to change the structure or content of our components as a means of clarifying the current recommendation, making it easier to learn, has a more intellectually appealing structure, etc. If we want to clarify the Recommendation, it must be in a manner that preserves wherever possible the structure (sorts) and contents (properties and their values) of the existing Schema 1.0 components.

Request concerning
Discussion history
23 Aug 2004, 19 Nov 2004

Transition history

raised on 18 Aug 2004 by Noah Mendelsohn
declined on 10 Dec 2004

RESOLVED: to close this issue, with thanks to the raiser.

Note that it remains in order to resist a decision on the grounds that it would break existing code or be otherwise inconvenient for existing implementations -- if a WG member objects to a proposed change to the component model on the grounds that it would adversely affect an existing API, they are not out of order.

Equally, it remains in order to propose changes to the component model or its description. If a WG member proposes or supports a change to the component model, they are not out of order even if other WG members believe that it would adversely affect an existing API.

In effect, the formal situation is exactly the status quo ante: things are as they were before, but we have clarified that it is neither out of order to change (or proposed to change) the component layer, nor to resist such changes.

Acknowledgment cycle
announced by group on 10 Dec 2004
agreement by reviewer on 10 Dec 2004

wd-20: Identity vs. Equality in enumerations and fixed value constraints [link to this issue]

In the call today we decided to use identity for value constraints, just as we do for enumeration, on the logic that a fixed value constraint is like an enumeration with a single value.

Noah and I expressed a certain discomfort with identity in both these cases, especially with respect to precision decimal. Consider:

<xs:simpleType name="u2numbers"> <xs:restriction base="xs:precisionDecimal"> <xs:enumeration value="1.0"/> <xs:enumeration value="2.0"/> <xs:enumeration value="3.0"/> <xs:enumeration value="14.0"/> </xs:restriction> </xs:simpleType>

We accepted that "1" and "1.00" would not be valid against this enumeration on the grounds that enumerations of decimals were not used in practice, so this infelicity was unlikely to bite anyone. The work-around would be to enumerate a sufficient range of precisions to cover the most likely cases to turn up in practice:

<xs:simpleType name="u2numbers"> <xs:restriction base="xs:precisionDecimal"> <xs:enumeration value="1"/> <xs:enumeration value="1.0"/> <xs:enumeration value="1.00"/> <xs:enumeration value="2"/> <xs:enumeration value="2.0"/> <xs:enumeration value="2.00"/> <xs:enumeration value="3"/> <xs:enumeration value="3.0"/> <xs:enumeration value="3.00"/> <xs:enumeration value="14"/> <xs:enumeration value="14.0"/> <xs:enumeration value="14.00"/> </xs:restriction> </xs:simpleType>

Painful in practice, impossible in the general case (although I suppose you could enumerate to the limits of precision supported by your processor, urgh.)

Or you put in a pattern facet instead, which can also be painful.

Consider this definition:

<xs:element name="meterMin" type="xs:precisionDecimal"/>

Somewhere in a content model:

<xs:element ref="meterMin" fixed="1.0"/>

In this case<meterMin>1.00</meterMin> and <meterMin>1</meterMin> would be rejected.

Here, however, there is no workaround that allows you the simplicity of using the fixed attribute: you have to change the type. If you wanted to have different fixed values for different uses of the element meterMin in your schema, you have to jump through some rather painful hoops using local definitions that have nasty enumerations or patterns in them: the type of each use of meterMin would have to be different.I still question the wisdom of using identity in either of these cases. Most types do not distinguish identity and equality, and in those cases that do, the results are unhelpful, as shown.

Request concerning
Part 1

Transition history

raised on 3 Dec 2004 by Mary Holstege
declined on 3 Dec 2004

RESOLVED No consensus to change status quo.

Acknowledgment cycle
announced by group on 3 Nov 2004
agreement by reviewer on 3 Nov 2004

wd-32: How do we calculate the value of a facet? [link to this issue]

Request concerning
Part 2

Transition history

raised on 18 May 2005 by Henry S. Thompson (ht@inf.ed.ac.uk), on behalf of Schema WG
declined on 19 May 2005

RESOLVED Close wd-32 with no action.

Acknowledgment cycle
announced by group on 19 May 2005
agreement by reviewer on 19 May 2005

wd-12: Content Model for Attributes [link to this issue]

It would be really useful to be able to create a content model for the attributes of an element, similar to that allowed by Relax NG, e.g. specify either attribute A, or B, or attributes C and D.

Although there are many situations where I use attributes when I should be using elements there are also times when I use elements when I should be using attributes simply to work around this limitation.

W3C has a number of XML languages that have dependencies between attributes. Some are acknowledged in the text and some are implicit. Either way it would be beneficial to reflect this dependency within the schema.

Request concerning

Transition history

raised on 4 Oct 2004 by Paul Duffin
Subsumed by issue(s) on 10 Dec 2004

We noted that wd-12 is subsumed by RQ-38


Maintained by Asir S Vedamuthu and Mary Holstege for XML Schema Working Group.

Last update: $Date: 2005/09/08 19:19:31 $


This page was generated as part of the Extensible Issue Tracking System (ExIT)