W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2009

[Bug 6522] Please un-deprecate the the namespace http://www.w3.org/2001/XMLSchema-datatypes

From: <bugzilla@wiggum.w3.org>
Date: Wed, 04 Feb 2009 01:56:46 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1LUX0Q-0000MC-J7@wiggum.w3.org>


--- Comment #2 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>  2009-02-04 01:56:46 ---
(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

[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 


denote the same datatypes as the corresponding names in the namespace


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


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
      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

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 4 February 2009 01:56:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:09 UTC