This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
QT approved comment: In 3.2.1, the definition of the value space of anySimpleType suffers from the fact that there are values here that have no lexical representation, for example the list consisting of two strings each comprising a single space. In addition, it's not clear whether a list containing a single item is the same value as that item. I don't know if these distinctions have any practical consequences but it's important to make the foundations as solid as possible.
The same error occurs in section 2.1, although not elsewhere, as far as I can tell by examining sentences containing the word 'mapping'. A possible solution is: (1) in section 2.1, replace [Definition:] In this specification, a datatype has three properties: ... * A small collection of functions, relations, and procedures associated with the datatype. Included are equality and order relations on the ·value space·, and a ·lexical mapping·, which is a function on the ·lexical space· onto the ·value space·. with [Definition:] In this specification, a datatype has three properties: ... * A small collection of functions, relations, and procedures associated with the datatype. Included are equality and order relations on the ·value space·, and a ·lexical mapping·, which is a mapping from the ·lexical space· onto the ·value space·. And (2) in section 2.3, replace the first paragraph [Definition:] The lexical mapping for a datatype is a prescribed function whose domain is a prescribed set of character strings (the ·lexical space·) and whose range is the ·value space· of that datatype. with (draft A): [Definition:] The lexical mapping for a datatype is a prescribed relation whose domain is a prescribed set of character strings (the ·lexical space·) and whose range is the ·value space· of that datatype. Note: For each primitive datatype defined here, the lexical mapping is a total function from the lexical space onto the value space of the datatype. For unions, the lexical mapping may or may not be a function; when a lexical representation maps to more than one value in the union, the choice of which value to use for further processing is determined by the order of the members of the union, or (when performing schema-validity assessment as defined in [XML Schema Part 1: Structures]) an xsi:type attribute in the document instance. For the special datatypes, the lexical mapping is not a function, since the same character sequence may map to several values. When a lexical representation maps to more than one value, the choice of which value to use for further processing is not determined by this specification; when performing schema-validity assessment as defined in [XML Schema Part 1: Structures], the value to be used may be determined by rules given there. In the case of anySimpleType, alone among datatypes defined here, the lexical mapping is also not a function onto the value space, because there are values with no lexical representation. or (draft B): [Definition:] The lexical mapping for a datatype is a prescribed relation whose domain is a prescribed set of character strings (the ·lexical space·) and whose range is the ·value space· of that datatype. Note: For each primitive datatype defined here, the lexical mapping is a total function from the lexical space onto the value space of the datatype. For unions and special datatypes, the lexical mapping is not a function, since the same character sequence may map to several values. When a lexical representation maps to more than one value, the choice of which value to use for further processing may be determined by rules given elsewhere (for unions, by the order of the members of the union; when performing schema-validity assessment as defined in [XML Schema Part 1: Structures] by rules given there; otherwise, by rules given in other specifications). For every datatype except anySimpleType, the lexical mapping maps *onto* the value space of the datatype (i.e., every member of the value space is mapped to by some lexical representation). In the case of anySimpleType, alone among datatypes defined here, the lexical mapping is also not a function onto the value space, because there are values with no lexical representation. or (draft C): [Definition:] The lexical mapping for a datatype is a prescribed relation whose domain is a prescribed set of character strings (the ·lexical space·) and whose range is the ·value space· of that datatype. Note: For each primitive datatype defined here, the lexical mapping is a total function from the lexical space onto the value space of the datatype. For unions and special datatypes, the lexical mapping is not a function, since the same character sequence may map to several values. When a lexical representation maps to more than one value, the choice of which value to use for further processing may be determined by rules given elsewhere. As currently defined, anySimpleType has values without lexical representations; that fact is noted in drafts A and B, but not C. It should also be noted in section 3.2.1, but that change is not part of this proposal; it belongs to bug 3243.
Apologies; comment #1 was added here by mistake; it belongs in bug 3025.
This issue is tied up with bug 3025 and bug 5058 and should be discussed together with them.
The XML Schema WG discussed this issue together with XML Query and XSL at the ftf meetings in October 2007 in Redmond. The discussion uncovered some new technical arguments, but we did not reach consensus. In particular, we noted that QT allows implementations to add new primitive datatypes, and regards those primitives as restrictions of anySimpleType. This means (some WG members argued) that the QT specs already entail an understanding of anySimpleType as including all atomic values, whether they are values of currently defined primitives or not. Other WG members argued that an alternative view would be that QT entails a view in which it doesn't matter in practice if different implementations have slightly different value spaces for anySimpleType. Analogous positions can be constructed regarding the addition of new primitive datatypes in future versions of XSDL and/or QT. Next steps: the chair does not propose to schedule this issue for further WG discussion until the editors have prepared one or more wording proposals for concrete consideration.
I did some musing on this on the flight home. It seems to me we identified two concepts, which I will call the "potential value space" and the "effable value space". The potential value space contains all values that meet the criteria implicit in the definition of the type. The effable value space contains that subset of the values that have a lexical representation. Rather than arguing about which of these is the one true meaning of the term "value space", it would seem useful (a) to introduce and name both concepts, (b) to explain that as far as the XSDL 1.1 spec is concerned, there would be no operational differences caused by using one concept rather than the other, but (c) because other specifications may use the same type system and allow means of constructing values other than by mapping from the lexical space, the term "value space" is taken to mean the "potential value space" unless otherwise specified. There is also another subset, of course, namely the "implemented value space", which takes into account implementation limitations on the range of values.
(In reply to comment #5) > There is also another subset, of course, namely the "implemented value space", > which takes into account implementation limitations on the range of values. Actually two subset concepts: One, the "implemented value space", which varies by implementation, and the other, the "minimal implemented value space", which is fixed by the partial-implementation minimum requirements prescribed in the spec.
The Working Group discussed the idea in comment #5 during our call of 26 October 2007. There was broad agreement that distinguishing between potential and effable value spaces, and introducing terms for them, would be useful; also that the special types should be described as having potential value spaces larger than their effable value spaces (because they contain ineffable values). There was disagreement over whether to say that list types had ineffable values in their potential value spaces or to say that for user-constructable list types, the potential value space and the effable value space are always the same. No consequence of the different formulations was identified which would be identifiable by means of schema-validity assessment; the main consequence would be for the use of list types in other contexts, and for compatibility of current list types with list types constructed using some future version of XSDL in which delimiters other than white space might be allowed. The status of the issue remains needsDrafting; the proposals prepared by the editors should be informed by the WG discussion, but no specific instructions were given.
A wording proposal intended to resolve this issue is available at http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b3025.html (member-only link).
The wording proposal mentioned in comment #8 was adopted by the XML Schema WG on its telcon today. Accordingly, I'm marking this issue resolved. Michael, as the originator of the issue, I hope you will (a) report back to the QT groups on its resolution and (b) signal your and their assent to this decision by changing the status of the bug to CLOSED, or your dissent by reopening it. If we have not heard from you within the next two weeks or so, we will assume that silence implies consent.