This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The XSD 1.1 Part 2 draft of 2009-01-30 claims: "The definition of a namespace separate from the main namespace defined by this specification proved not to be necessary or helpful in facilitating the use, by other specifications, of the datatypes defined here." On the contrary, this namespace is heavily used by authors of RELAX NG schemas who wish to make use of the XSD2 datatypes. (RELAX NG allows fully user-specified primitive and derived datatypes, and the forthcoming DTLL language will provide a method for declaratively specifying them.) In fact, this namespace is built in to the RELAX NG compact syntax: for schemas written in that syntax, the mapping of the namespace prefix "xsd" (not "xs") to this namespace is presumed by the RELAX NG processor. I can't speak to the further claim "[the use of this namespace] raises a number of difficult unsolved practical questions", as I don't know what those questions might be. I would have no objection, however, to deprecating the use of this namespace in XML Schemas.
For information, the problems with this namespace centred on the question of whether or not the types in this namespace are identical to the types in the primary XSD namespace, or derived from them. Derivation doesn't work, because there is no multiple inheritance, so (using prefixes xs and xsd to distinguish the namespaces) xsd:long cannot be derived both from xs:long and from xsd:integer. So the only way to make these types work is by some sort of claim that the namespace URIs are synonymous. But we don't have any formal way of making that claim true; if two schema components have different {target namespace} properties, then they are by definition distinct.
(Speaking only for myself, not for the WG.) John, thank you for calling this issue to our attention. For the record, the change in question was adopted by the XML Schema WG at a call on 13 January 2006 as a resolution of bug 2214 (q.v.), with the relatively laconic comment in the minutes that Point of information: QT not referencing it, semantic web best practices has no reference from their document, Googling returns references, but seem to be from tutorials. MSM found one live use in metadata for collection of (geospatial?) data. And more uses in drafts of other specs, but newer drafts removed. (http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2006Jan/0036.html [member-only link]) From the wording in the minutes, it appears that the rationale for thinking the change would be harmless to the world might be effectively undercut by a reference to a normative document for Relax NG that does refer to the namespace in question. A quick Google search for the namespace name turns up a Relax NG tutorial at http://relaxng.org/tutorial-20011203.html but no normative document. John, can you possibly oblige with a reference? It would perhaps help persuade members of the WG that the facts are not now as we thought they were when the decision was made. I think the reasoning behind the change has been ably summarized in comment 1 by Michael Kay, at least as far as I have so far been able to remember it, under the influence of the report at bug 2214 and the minutes linked from there. If we do wish to reverse the deprecation, perhaps the right way to make the magic of the matter less mysterious is to call it out, front and center, and specify it very bluntly: certain classes of processors (who?) are required to recognize that the names in the namespace http://www.w3.org/2001/XMLSchema-datatypes denote the same datatypes as the corresponding names in the namespace http://www.w3.org/2001/XMLSchema We may be aided in this by the fact that in XSD 1.1 we have worked with at least partial success to make the term "datatype" have an extensional, not an intensional, sense, and we specify clearly that different simple type definitions can define the same datatype. It is not clear to me at the moment whether it matters whether names like {http://www.w3.org/2001/XMLSchema-datatypes}decimal {http://www.w3.org/2001/XMLSchema}decimal are defined as, or are in practice taken as, denoting (a) just the datatypes in question, not the simple type definitions, (b) both the datatypes and the simple type definition, which are after all closely related, or (c) huh? what are you talking about? I suspect that among editors of specs for the various language at issue here, opinion may be divided among (a) and (b), at least until someone goes to look up just what words are used in the spec, and that among implementors and users of the various technologies involved, answer (c) is likely to predominate. In any case, if we are going to undeprecate the datatypes namespace, we are going to need some story about what its names denote. I see three stories to choose from: (a) they denote the datatypes, but not the simple type definitions; that is, they have lexical spaces, value spaces, lexical mappings, and the like, but not necessarily unique names or {target namespace} properties. (b) they denote the simple type definitions in the XMLSchema namespace, and (by metonymy) the datatypes which are the extensional interpretations of those simple type definitions. That is, for example, the expanded name {http://www.w3.org/2001/XMLSchema-datatypes}decimal denotes the following simple type definition: {name} = decimal {target namespace} = 'http://www.w3.org/2001/XMLSchema' {base type definition} = anyAtomicType Definition {final} = The empty set {variety} = atomic {primitive type definition} = [this Simple Type Definition itself] {facets} = a whiteSpace facet with {value} = collapse {fixed} = true {fundamental facets} = { ordered = total bounded = false cardinality = countably infinite numeric = true } {context} = absent {item type definition} = absent {member type definitions} = absent {annotations} = The empty sequence Note that the namespace portion of the expanded name is not the same as the target namespace of the simple type definition. This will cause some readers (and possibly WG members) heartburn, to which the only possible response is: get over it. (c) They denote what they have always denoted, whatever that is, but we continue to deprecate their use on the grounds that no one is really comfortable saying just what it is. (d) They denote the simple type definitions, as described in (b), but not the datatypes, which are different kinds of things. Metonymy is to be frowned upon. John, since the use of the Datatypes namespace by Relax NG appears to be the major (or rather: only) argument thus far advanced in favor of undeprecating the namespace, it would be very helpful to know whether the differences among interpretations (a), (b), and (d) (or even (c)) matter for RelaxNG's purposes, and which interpretation is most helpful to RelaxNG's use of the XSD datatypes. It would be helpful to have your view; it would be even more helpful to have the views of the editors of the RelaxNG spec, or the groups responsible for maintaining it,
RELAX NG references the namespace in two places: http://www.oasis-open.org/committees/relax-ng/xsd-20010907.html#IDAZCYR http://www.oasis-open.org/committees/relax-ng/compact-20021121.html#formal-syntax I don't think anything is going to break if XSD deprecates the namespace, but it would be nicer if RELAX NG didn't end up using a namespace that the W3C had deprecated. As between the various interpretations, I think (a) would be cleaner, but (b) would be fine too.
FWIW, I think it should define (a) -- the abstract notion of the datatypes themselves rather than the simple type definitions. This enables other datatype definition languages (such as DTLL) to use them without implying a particular method of definition. I suppose it *could* form a basis for distinguishing between {http://www.w3.org/2001/XMLSchema}decimal and {http://www.w3.org/2001/XMLSchema-datatypes}decimal if the first was the simple type definition and the second the datatype itself, but I don't know if that would work.
I think there is no problem having multiple names for the same type until you start to support reflection. As soon as you provide interrogatives that allow you to ask "what is the name of this type?" or "what is the name of the type of this value?", you hit trouble if the type has more than one name.
I have to confess I'm very much in the: (c) huh? what are you talking about? camp! But do we really need a convincing story in XSD about the differences between the two namespace in order just to preserve the http://www.w3.org/2001/XMLSchema-datatypes namespace when it doesn't really add value to XSD itself and represents just another element of confusion for the reader? Can't we say something along the lines of: "For historical reasons the namespace http://www.w3.org/2001/XMLSchema-datatypes is reserved as an alias of http://www.w3.org/2001/XMLSchema when referring to XSD datataypes so that it may be used by other specifications to refer to the data types defined herein, such that blah-di-blah." ?
(In reply to comment #5) > I think there is no problem having multiple names for the same type until you > start to support reflection. As soon as you provide interrogatives that allow > you to ask "what is the name of this type?" or "what is the name of the type of > this value?", you hit trouble if the type has more than one name. We should note that--as currently defined--a datatype does not have a name. One function of a simple type definition is to identify a datatype and attach a name to it. Note also that many of the auxiliary terms defining additional attributes (generic, not in the XML sense) require that one look at the mechanism used to associate one datatype with another; of course, in XSD processing that mechanism is that defined in 2.4 . If a different mechanism is used, the concepts defined in 2.4 may or may not be useful. However, using the names associated by this spec to identify datatypes does not require that one adopt the simple-type-definition mechanism; this spec adopted that mechanism and associated datatypes with names. Others are free to use those names to identify datatypes in which they are interested, without adopting that selection mechanism for identifying additional datatypes. Given that observation, it's not clear to me why a user would need to use the now-deprecated namespace. For that matter, even a user who wants to use only the simple-type-definition mechanism can certainly use the simple type definitions from the other namespace. On the other hand, it appears that the only reason for deprecating the alternate namespace is because some definition-dependent attributes may not give expected answers--but why would one choose to use both namespaces willy-nilly in the first place? This is beginning to feel like a tempest in a teapot.
>We should note that--as currently defined--a datatype does not have a name. Technically this is true, we say: "Different simple type definitions with different selections of facets can describe the same datatype. " So, for example, a restriction of xs:string with the pattern facet "x|y" describes the same datatype as a restriction of xs:string with the enumeration facet ("x", "y"). Fortunately, however, this is a fact that we never take advantage of; we never require a processor to detect that these are the same datatype (in general, it may be impossible to do so). This means that the fact that they are the same has no observable consequences and therefore should probably not have been stated in the specification. Any use of reflection or introspection, as I discussed in comment #5, would almost certainly relate to type definitions rather than datatypes per se. In any processing system that annotates values with types, the annotation is likely in practice to be a type definition rather than a "pure" datatype. And of course the relations such as "is derived from" are properties of type definitions, not to datatypes. So the fact remains, that having two type definitions that are "identical except in name" causes us problems.
Comment #8 appears to net out to an argument in favor of interpretation (a) over (b), (c), or (d), if we wish to explain what the names in the datatypes namespace denote. I think (a) is compatible with saying that XSD validators are not expected to recognize names in the datatypes namespace, or do anything special with them. The datatypes namespace, in this story, is for the convenience and use of those who wish to name the built-in datatypes without naming the built-in type definitions which describe them; XSD validators are not in that situation. Since (a) appears to fit a little better with the one use of the datatypes namespace we are now aware of, (a) seems just now like the least-cost highest-value resolution to this issue. On a side note, comment #8 also suggests that it was as mistake to say, in the spec, that different simple type definitions can describe the same datatype, since "the fact that they are the same has no observable consequences". You may be right, but I respectfully disagree both with the conclusion and with the premise. Any spec defines concepts for use as tools in talking and thinking (and not solely for use in conformance checking); among those defined by XSD 1.1 Datatypes are "datatype" and "simple type definition". Since the two are intimately interconnected but distinct, identifying many-to-one relations between them can help make clear how they differ, even if the fact of the many-to-one relation were not observable or had no consequences for validator conformance. But in fact, I think it is observable that in the following example, the simple type definitions s1, s2, and s3 describe the same datatype. <xsd:simpleType name="s1"> <xsd:restriction base="xsd:integer"> <xsd:minExclusive value="0"/> <xsd:maxInclusive value="3"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="s2"> <xsd:restriction base="xsd:short"> <xsd:minInclusive value="1"/> <xsd:maxInclusive value="3"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="s3"> <xsd:restriction base="xsd:decimal"> <xsd:enumeration value="1"/> <xsd:enumeration value="2"/> <xsd:enumeration value="3"/> </xsd:restriction> </xsd:simpleType> So it seems to me that there are observable consequences to the fact in question.
>I think it is observable that in the following example Sorry, I don't get your point. What exactly would the observable difference be if the types described by these three type definitions (or rather, the three type definitions of which these are the XML representations) were regarded as distinct? Would any document instance validate differently? Would any query give a different answer?
(In reply to comment #10) > >I think it is observable that in the following example > > Sorry, I don't get your point. What exactly would the observable difference be > if the types described by these three type definitions (or rather, the three > type definitions of which these are the XML representations) were regarded as > distinct? Would any document instance validate differently? Would any query > give a different answer? > It seems to me (and I speak from profound ignorance) that if types S1 and S2 are nominally distinct though structurally identical, that one cannot infer that if T1 is derived from S1, it is also compatible with S2.
(In reply to comment #2) > (Speaking only for myself, not for the WG.) > > John, thank you for calling this issue to our attention. > > For the record, the change in question was adopted by the XML Schema > WG at a call on 13 January 2006 as a resolution of bug 2214 (q.v.), > with the relatively laconic comment in the minutes that > > Point of information: QT not referencing it, semantic web best > practices has no reference from their document, Googling returns > references, but seem to be from tutorials. > > MSM found one live use in metadata for collection of (geospatial?) > data. And more uses in drafts of other specs, but newer drafts > removed. > > (http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2006Jan/0036.html > [member-only link]) > > From the wording in the minutes, it appears that the rationale for > thinking the change would be harmless to the world might be > effectively undercut by a reference to a normative document for Relax > NG that does refer to the namespace in question. A quick Google > search for the namespace name turns up a Relax NG tutorial at > http://relaxng.org/tutorial-20011203.html but no normative document. > > John, can you possibly oblige with a reference? It would perhaps help > persuade members of the WG that the facts are not now as we thought > they were when the decision was made. The bibliographical reference is ISO/IEC 19757-2:2003/Amd.1:2006(E), clause C.4, Declarations. The relevant text reads: A datatypes declaration declares a prefix used in a QName identifying a datatype. For example, datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes" element height { xsd:double } In fact, in the above example, the datatypes declaration is not required: the xsd prefix is predeclared to the above URI. > I think the reasoning behind the change has been ably summarized in > comment 1 by Michael Kay, at least as far as I have so far been able > to remember it, under the influence of the report at bug 2214 and the > minutes linked from there. > > If we do wish to reverse the deprecation, perhaps the right way to > make the magic of the matter less mysterious is to call it out, front > and center, and specify it very bluntly: certain classes of processors > (who?) are required to recognize that the names in the namespace > > http://www.w3.org/2001/XMLSchema-datatypes > > denote the same datatypes as the corresponding names in the namespace > > http://www.w3.org/2001/XMLSchema > > We may be aided in this by the fact that in XSD 1.1 we have worked > with at least partial success to make the term "datatype" have an > extensional, not an intensional, sense, and we specify clearly that > different simple type definitions can define the same datatype. > > It is not clear to me at the moment whether it matters whether names > like > > {http://www.w3.org/2001/XMLSchema-datatypes}decimal > {http://www.w3.org/2001/XMLSchema}decimal > > are defined as, or are in practice taken as, denoting (a) just the > datatypes in question, not the simple type definitions, (b) both the > datatypes and the simple type definition, which are after all closely > related, or (c) huh? what are you talking about? > > I suspect that among editors of specs for the various language at > issue here, opinion may be divided among (a) and (b), at least until > someone goes to look up just what words are used in the spec, and that > among implementors and users of the various technologies involved, > answer (c) is likely to predominate. > > In any case, if we are going to undeprecate the datatypes namespace, > we are going to need some story about what its names denote. I see > three stories to choose from: > > (a) they denote the datatypes, but not the simple type definitions; > that is, they have lexical spaces, value spaces, lexical > mappings, and the like, but not necessarily unique names > or {target namespace} properties. > > (b) they denote the simple type definitions in the XMLSchema > namespace, and (by metonymy) the datatypes which are the > extensional interpretations of those simple type definitions. > > That is, for example, the expanded name > {http://www.w3.org/2001/XMLSchema-datatypes}decimal > denotes the following simple type definition: > > {name} = decimal > {target namespace} = 'http://www.w3.org/2001/XMLSchema' > {base type definition} = anyAtomicType Definition > {final} = The empty set > {variety} = atomic > {primitive type definition} = [this Simple Type Definition itself] > {facets} = a whiteSpace facet with > {value} = collapse > {fixed} = true > {fundamental facets} = { > ordered = total > bounded = false > cardinality = countably infinite > numeric = true > } > {context} = absent > {item type definition} = absent > {member type definitions} = absent > {annotations} = The empty sequence > > Note that the namespace portion of the expanded name is not the > same as the target namespace of the simple type definition. > This will cause some readers (and possibly WG members) > heartburn, to which the only possible response is: get over it. > > (c) They denote what they have always denoted, whatever that is, > but we continue to deprecate their use on the grounds that no one > is really comfortable saying just what it is. > > (d) They denote the simple type definitions, as described in (b), but > not the datatypes, which are different kinds of things. Metonymy > is to be frowned upon. > > John, since the use of the Datatypes namespace by Relax NG appears to > be the major (or rather: only) argument thus far advanced in favor of > undeprecating the namespace, it would be very helpful to know whether > the differences among interpretations (a), (b), and (d) (or even (c)) > matter for RelaxNG's purposes, and which interpretation is most > helpful to RelaxNG's use of the XSD datatypes. It would be helpful to > have your view; it would be even more helpful to have the views of the > editors of the RelaxNG spec, or the groups responsible for maintaining > it, I think, agreeing with most other posters, that (a) is the most useful choice for RELAX NG purposes.
(In reply to comment #12) > The bibliographical reference is ISO/IEC 19757-2:2003/Amd.1:2006(E), clause > C.4, Declarations. I forgot to add that to reach this text online, you must go to http://standards.iso.org/ittf/PubliclyAvailableStandards/c040774_ISO_IEC_19757-2_2003_Amd_1_2006(E).zip , click "I Accept" on the single-user license, download and unpack the zipfile, and go to page 5 of the enclosed PDF.
I want to be sure we are all on the same page WRT existing terminology and relationships. Then we can decide what if anything should be changed. Section 3: "Each built-in datatype defined in this specification can be uniquely addressed via a URI Reference constructed as follows:" (The URI "addresses" the datatype.) Section 3.1: "the ·built-in· datatypes in this specification have the namespace name http://www.w3.org/2001/XMLSchema". (The datatype "has" the namespace name, which happens to be the same as that in the URI that "addresses" the datatype, as well as the value of the {target namespace} of the simple type definition prescribed in 4.1.6.) Section 3.1: "each non-·special· ·built-in· datatype is also defined in the namespace whose URI is http://www.w3.org/2001/XMLSchema-datatypes". (So these datatypes are also "defined in" a different namespace.) Where does this terminology lead us? First of all, we can "address" built-in datatypes using a URI specified by an algorithm in section 3. OTOH, these same datatypes are also "defined in" a different namespace. The spec doesn't explicitly say that that other namespace can be used to create URIs that "address" these datatypes, but it can certainly be read to imply that. What does it mean to be "defined in" a namespace? One reasonable interpretation might be that there is a prescribed simple type definition which selects and names the datatype and uses that namespace's name as its {target namespace} value. With this interpretation, we must infer the existence of a set of s-t-ds that parallel the ones described in 4.1.6, but with a different {target namespace} value. Finally: What's the "name" of a datatype? I think it's reasonable to say that, if the datatype is "named" by a simple type definition, then its name is the expanded name (in the namespace spec sense) formed by the s-t-d's {target namespace} value and its (local part) {name} value. The URIs that we assert in Section 3 to "address" the datatypes, by this definition of "name" are in fact the "names" of the datatypes. Given the above interpretation of "defined in", then there is another set of defining s-t-ds with a different {target namespace} value giving rise to another set of expanded names naming the same datatypes. Whew! Question: Should these expanded names (1) name the datatype (as they appear to do now), or should (2) they both name the simple type definitions, or (3) both name both the s-t-d and datatype by metonymy--or (4) one name the s-t-d and the other the datatype? Another way to look at it: Does the expanded name composed from the {target namespace} and {name} of a given simple type definition name the s-t-d, the associated datatype, or both (depending on context)? Or (for option (4)) can we prescribe that some name one and some name the other? I'd say that option (4) is the hardest one to justify. OTOH, I think that it would be a shame for the (XSD) Schema spec not to provide names for the simple type definition schema components, but it's clear that users such as RELAX NG want names for the datatypes themselves. This leads us to option (3), which is also Michael Sperberg-McQueen's option (b). Perhaps more important: What harm arises from having more than one name for a datatype? as Michael Kay says, it seems that problems arise only when one is concerned with reflection. My reaction is that in such a circumstance, the reflecting mechanism must specify what set of names for datatypes it is using. Nothing can prevent someone from introducing another simple type definition or other naming mechanism that names an already-named datatype--so I think the system that intends to reflect those names must say what names it will use or provide users with a mechanism for specifying what names they will expect. Then if the user specifies names including more than one name for one datatype, it's the user's problem. WRT comment 4, which worries about enabling "other datatype definition languages (such as DTLL) to use [XSD-spec-prescribed names] without implying a particular method of definition": Since datatypes don't intrinsically have names, any naming mechanism must be able to select a particular already-(extrinsically)-existing datatype and attach a name to it. "Defining" the datatype is just the intrinsic-point-of-view version of extrinsic "selection". It's perfectly acceptable to use the XSD-selected/defined datatypes and their XSD-attached names without prescribing that that selection/definition mechanism be used for naming additional datatypes. I've come to the conclusion that there was really no value in introducing both namespaces, but having done so there is no harm in having them. We certainly can use one or the other to indicate whether or not we intend to use the XSD selection/definition mechanism for other definitions--even though a system receiving the name should not care, and a system producing such a name should probably try to be consistent. In lieu of deprecating using the extra namespace, perhaps we need a Note warning that using systems should explain to their users the difficulties (if any) that system might get into if said user were to introduce more than one name for a given datatype--and of course said systems should not themselves introduce (e.g., by intrinsically recognizing theURIs) more than one such name. Too many words, but I don't know how to say it shorter. Sorry. Needless to say, once we realize what the nuances are of the terminology we use, I don't propose explaining in the spec all those nuances to newbie readers. I just want us to use the various terms consistently, and hopefully have them defined carefully enough that the nuances do follow from the definitions, for those who wish to worry about said nuances.
So, given all of that, I propose that the WG take the following actions: 1) undeprecate the use of the namespace 2) add explanatory text (based on Michael's 'a'), i.e. "they denote the datatypes, but not the simple type definitions" 3) add a further comment that gives the following sort of information "this namespace is provided to make it easy for other specifications to reference the datatypes. Note that will inevitably be some magic in that referencing. Such magic is defined by them, and not by the XML Schema WG." Obviously we won't say "magic" but that's the idea. So it won't be deprecated, but it will be clearly stated that we're not going to try to define exactly what it means, either. And we stop just short of saying that trying to define it is beyond our ability.
(In reply to comment #15) > So, given all of that, I propose that the WG take the following actions: > > 1) undeprecate the use of the namespace > 2) add explanatory text (based on Michael's 'a'), i.e. "they denote the > datatypes, but not the simple type definitions" What's "they"? Both sets of URIs? Only those in the deprecated namespace? Right now the undeprecated namespace URIs explicitly "address" the datatypes. Nothing is said about referencing simple type definitions. > 3) add a further comment that gives the following sort of information > "this namespace is provided to make it easy for other specifications to > reference the datatypes. Can someone explain why one "address" for the datatypes is easier to use to reference the datatypes than the other? > Note that will inevitably be some magic in that > referencing. Such magic is defined by them, and not by the XML Schema WG." What is it that the "addressing" URI references--in either case? How does either reference/address a datatype without the same magic?
(In reply to comment #16) > > 3) add a further comment that gives the following sort of information > > "this namespace is provided to make it easy for other specifications to > > reference the datatypes. > > Can someone explain why one "address" for the datatypes is easier to use to > reference the datatypes than the other? It doesn't, of course. But in version 1.0, it was put in with that as the stated purpose, and other specifications have indeed used it for that very purpose. Yanking it now makes no sense.
ACTION 2009-02-06.1: editors to prepare a wording proposal to resolve bug 6522 by undeprecating the namespace in question and providing a clarification of what that namespace means.. [recorded in http://www.w3.org/2009/02/06-xmlschema-minutes.html#action02]
(In reply to comment #18) > ACTION 2009-02-06.1: editors to prepare a wording proposal to resolve bug 6522 > by undeprecating the namespace in question and providing a clarification of > what that namespace means.. [recorded in > http://www.w3.org/2009/02/06-xmlschema-minutes.html#action02] http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2009Feb/att-0000/2009-02-06telcon.html#action02 will be accessible to more people, I suspect.
A wording proposal intended to resolve this issue is at http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b6522.html (member-only link) and awaits action by the WG.
- 6522 (John Cowan): Please un-deprecate the the namespace http://www.w3.org/2001/XMLSchema-datatype The proposal is at: http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b6522.html Summary: reverts most of the earlier change that deprecated the namespace. After this change, the relevant part of 3.1 will read: To facilitate usage in specifications other than the XML Schema definition language, such as those that do not want to know anything about aspects of the XML Schema definition language other than the datatypes, each ·built-in· datatype is also defined in the namespace whose URI is: http://www.w3.org/2001/XMLSchema-datatypes Note: The status quo says "each non-special built-in datatype ...:, We added 'non-special' when we deprecated the namespace, probably on the theory that (1) anySimpleType is not in the namespace as described in 1.0 and (2) if we were going to deprecate it, it made no sense to 'maintain' it or bring it up to date. I propose to revert the change for simplicity: "all built-ins" is simpler than "all non-special built-ins". Reliable authority says RelaxNG doesn't care and can live with specials in the namespace or not in the namespace. MSM's recommendation: Quick. Adopt proposal as shipped.
The changes described in comment 21 have been integrated into the status quo document at http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.html Accordingly, I'm marking this issue RESOLVED / FIXED. John, please let us know if you agree with this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next ten days or so, we will assume you agree with the WG decision.
I agree with and accept the adopted resolution.