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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6522





--- Comment #14 from Dave Peterson <davep@iit.edu>  2009-02-05 03:50:20 ---
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.


-- 
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 Thursday, 5 February 2009 03:50:32 UTC