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.
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.
Color key: error warning note
Id: Title | State | Type | Open actions | Ack. |
---|---|---|---|---|
wd-23 : Misleading - Schema Component Constraint: applicable facets | no decision (raised) | editorial | ||
wd-27 : Errors in component diagram | no decision (raised) | editorial | ||
wd-30 : Fundamental facet table is messed up | no decision (raised) | editorial | ||
wd-31 : 1.1 working draft and unicode | no decision (raised) | editorial | ||
wd-1 : "constructed from ID" vs. "derived from ID" in Structures | no decision (raised) | error | ||
wd-22 : Applying default values of type QName (and NOTATION) | no decision (raised) | error | ||
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 3896 | no decision (raised) | proposal | ||
wd-28 : Proposal from the i18n-core wg for changes of anyURI | no decision (raised) | proposal | ||
wd-29 : URI changes in RFC 3986 | no decision (raised) | proposal | ||
wd-4 : Confusing description of equality | agreed | editorial |
| No response to reviewer |
wd-5 : Editorial comments | agreed | editorial |
| No response to reviewer |
wd-3 : Confusing description of identity, specifically a warning in section 2.2.2 | agreed | error |
| No response to reviewer |
wd-7 : error in timeOnTimeline function | agreed | error |
| No response to reviewer |
wd-11 : Incorrect definition of the {facets} property | agreed | error |
| No response to reviewer |
wd-13 : Underspecification in fallback to lax processing | agreed | request |
| No response to reviewer |
wd-34 : What are the rules for list equality? | agreed | request |
| No response to reviewer |
wd-6 : Summary of Changes | subsumed | editorial | ||
wd-9 : Error in derived-from-duration regexes | subsumed | error | ||
wd-10 : Error in setDateTimeFromRaw procedure | subsumed | error | ||
wd-15 : gDay and setDateTimeFromRaw edge case | subsumed | error | ||
wd-16 : gDay and timeOnTimeLine edge case | subsumed | error | ||
wd-12 : Content Model for Attributes | subsumed | request | ||
wd-14 : Editorial note on section 5.2 | agreed | editorial |
| Agreement |
wd-17 : Suggested replacement text for 3.2.7.1 | agreed | editorial | No response to reviewer | |
wd-2 : "fixed value constraint" based on identity or equality | agreed | error |
| Agreement |
wd-21 : Canonical representation of QName/NOTATION values | agreed | error |
| Agreement |
wd-26 : When did timezones cease being durations? | agreed | error |
| Agreement |
wd-19 : base64 and linefeeds | agreed | proposal |
| Agreement |
wd-33 : Are lexical maps functions or relations? | agreed | request |
| Agreement |
wd-8 : Do not change anything that affects our code, unless something important | declined | request | Agreement | |
wd-20 : Identity vs. Equality in enumerations and fixed value constraints | declined | request | Agreement | |
wd-32 : How do we calculate the value of a facet? | declined | request | Agreement |
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.
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
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
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/
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?
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.)
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.
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.
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
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/
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.
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?
Assign to editors to fix
Editors to attempt to resolve wd-3 and wd-4 in the next working draft
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"
Assign to editors to fix
Editors to attempt to resolve wd-5 in the next working draft
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.
Assign to editors to fix
Editors to attempt to resolve wd-3 and wd-4 in the next working draft
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.
ACTION 20050429-01 editors to prepare proposal on wd-7.
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.
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).
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)
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 to make {facets} not include fundamental facets
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.
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.
We have a resolution
Structures editors to produce wording proposal for wd-13.
Datatype editor to resolve R-181 by defining identity and equality of lists in terms of pairwise member identity and equality, respectively.
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.
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.
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.
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.
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.
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
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.
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.
RESOLVED: to close issue wd-14 by accepting the second proposed wording.
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.
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."
RESOLVED: Ashok's recommendation approved as amended (leave the box alone)
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.
Editors to attempt to resolve wd-17 in prescribed in the issue and as ammended in the telcon in the next working draft.
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?
RESOLVED Close wd-2 by instructing the editors to treat fixed value constraints the same as enumeration with regards to identity vs equality.
Editors to treat fixed value constraints the same as enumeration with regards to identity vs equality.
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?
Decided to add a health warning about canonical forms.
Editors to implement the health warning about canonical forms.
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.
RESOLVED Close wd-16 by instructing editors to reintroduce the word 'duration', but not the claim that it is an instance of xs:duration.
DT editors to prepare an editorial proposal to resolve wd-33.
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.
MSM proposed that we agree with the comment; no dissent.
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.)
Awaiting proposal from the editors.
DT editors to prepare an editorial proposal to resolve wd-33.
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.
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.
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.
Last update: $Date: 2005/09/08 19:19:30 $
This page was generated as part of the Extensible Issue Tracking System (ExIT)
Copyright © 2003, 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.