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

[Bug 3232] Type versus Datatype

From: <bugzilla@wiggum.w3.org>
Date: Tue, 05 Feb 2008 03:23:44 +0000
CC:
To: www-xml-schema-comments@w3.org
Message-Id: <E1JMEPQ-00085J-Rp@wiggum.w3.org>

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





------- Comment #3 from davep@iit.edu  2008-02-05 03:23 -------
(In reply to comment #2)
> I might mention that I've been having the same problem with the words "type"
> and "data type" (and "datatype") in my XSLT book; the copy editors have been
> going crazy trying to get the usage consistent, and in the end I've given up
> and decided that "data" adds nothing to the sense, so it's been removed
> everywhere. This seems to work perfectly well once you get used to it. Types
> partition into complex and simple, simple types partition into union, list, and
> atomic: there's no room in this hierarchy for another adjective "data". (What
> do you call a type that isn't a data type?)

Well, SGML had element types defined by element type defintions, and they were
specific subsets of the class of elements.  I generally found that in OO
terminology, "types" were subsets of a class that were effectively defined by a
specified mechanism applied to certain objects, which were equated with the
subclass they defined.  An object *has* properties and a class restricts
properties; if several objects use their property values to further restrict
the instances of a class according to the same rule, they are
"types" of that class.  E.g., the class is element; the objects have certain
properties; element type definitions specify values for the properties; the
resulting objects are element *types* whose property values select out certain
subclasses of element according to a uniform rule.

As I see it, simple and compound types are intermediate between element and the
element types of XML (defined by the unfortunately renamed "element
definition", really still an element type definition).  As such, they define
subclasses of element (i.e., the class of which elements and only elements are
instances).

Accordingly, we still have element types, we have simple types, we have complex
types; they all are subclasses of element.  The things we define in Part 2 and
call datatypes are different animals.  And we have four different things we
call "types"; I think we should try to consistently say which kind we're
talking about.

We did feel that if we always called them datatypes in text, we didn't have to
rename the names of the properties, which could cause possibly significant
reprogramming for those systems that choose to use our abstractions to define
their user interface or API.

> The most prominent usage of "Datatypes" is of course in the title of part 2,
> which should probably be "Simple Types".

I disagree;  a simple type is a subclass of element.  Our datatypes are not
classes of elements.  They are what mathematicians and logicians sometimes call
"mathematical systems" and computer scientists often call "datatypes".
Received on Tuesday, 5 February 2008 03:23:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:13:12 GMT