This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1909 - RQ21: BNF, regex, etc for special types (anySimpleType, anyAtomicType)
Summary: RQ21: BNF, regex, etc for special types (anySimpleType, anyAtomicType)
Status: RESOLVED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Datatypes: XSD Part 2 (show other bugs)
Version: 1.1 only
Hardware: PC Linux
: P3 major
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords: resolved
Depends on:
Blocks: 1837
  Show dependency treegraph
 
Reported: 2005-08-30 16:16 UTC by C. M. Sperberg-McQueen
Modified: 2006-01-15 00:25 UTC (History)
0 users

See Also:


Attachments

Description C. M. Sperberg-McQueen 2005-08-30 16:16:03 UTC
As part of discharging RQ-21 (provide regex and/or BNF for all primitive
types), define a BNF and/or regex and describe explicitly the lexical 
mapping and canonical mapping for xsd:anySimpleType and xsd:anyAtomicType.

(Since the lexical mapping for these types is not a function but
a relation, there will be no canonical mapping, and the description
of the lexical mapping may be just a statement that it's the union
of all the lexical mappings for the primitive types.)
Comment 1 C. M. Sperberg-McQueen 2005-09-09 02:42:13 UTC
A draft proposal (diff group rq21-specials-1909) is ready
for review by the other editors, and publication
to the WG.
Comment 2 C. M. Sperberg-McQueen 2006-01-04 13:21:03 UTC
A draft wording proposal was sent to the Working Group 15 Dec 2005
for consideration.  It makes explicit that the lexical mapping
relation for the special types is not a function.  The relevant part
of the proposal for anySimpleType reads as follows; similar text
is provided for anyAtomicType.


3.2.1.1 Value space

The .value space. of anySimpleType is the union of the .value
spaces. of all the .primitive. datatypes defined here, and of all
sets of lists formed from the members of the
.primitive. datatypes.

At least in theory, the .value space. of anySimpleType also
includes all values of anything that might in future be added to
the set of .primitive. datatypes, as well as lists including
those values. That is, users of the datatypes defined here should
not assume that the .value space. of anySimpleType is limited to
values in the .primitive. datatypes defined in this version of
this specification. They might be values from other datatypes not
defined here.


3.2.1.2 Lexical mapping

The .lexical space. of anySimpleType is the set of all
finite-length sequences of characters (as defined in [XML]) that
.match. the Char production from [XML]. This is equivalent to the
union of the .lexical spaces. of all .primitive. datatypes.

The .lexical mapping. of anySimpleType is the union of the
.lexical mappings. of all .primitive. datatypes and all list
datatypes. It will be noted that this mapping is not a function:
a given literal may map to one value or to several values of
different .primitive. datatypes, and it may be indeterminate
which value is to be preferred in a particular context. When the
datatypes defined here are used in the context of [XML Schema
Part 1: Structures], the xsi:type attribute defined by that
specification in section xsi:type can be used to indicate which
value a literal which is the content of an element should map
to. In other contexts, other rules (such as type coercion rules)
may be employed to determine which value is to be used.


3.2.1.3 Facets

When a new datatype is defined by .facet-based restriction.,
anySimpleType must not be used as the .base type.. So no
.constraining facets. are directly applicable to anySimpleType.
Comment 3 Noah Mendelsohn 2006-01-04 20:26:44 UTC
> When a new datatype is defined by .facet-based restriction.,
anySimpleType must not be used as the .base type.

Should that be MUST NOT (I.e., in capital letters?)

Noah
Comment 4 C. M. Sperberg-McQueen 2006-01-15 00:25:49 UTC
The Working Group adopted the wording proposal, with amendments,
on its telcon of 13 January 2006.  The amendments included 
deleting the paragraph about the special types including the
value spaces of future primitive datatypes, and a restatement
of what the lexical space of anySimpleType is equivalent to.

Rationale for the deletion of the paragraph varied.  Some WG
members preferred to think that as new primitive types are
added, the value space and lexical mapping of the special types
change.  Others were alarmed by the realization that including
in the value space the values of primitive types currently
unknown entails the existence, in a value space, of ineffable
values, in violation of the invariant that the value space 
and lexical space of any type are, respectively, the range
and domain of its lexical mapping.

For whatever reason, there was no consensus in the WG in favor
of the paragraph, and it was accordingly deleted.