Re: ISSUE-126 (Revisit Datatypes): A new proposal for the real <-> float <-> double conundrum

[Since this discussion is going to other lists, let me explain that I'm
a member of the Schema WG, and I work primarily on datatypes.  Although
this message was directed from Alan Ruttenberg to Rob Shearer, I'm
going to inject comments since it went to the general WG lists as
well.]

At 4:56 PM -0400 2008-07-04, Alan Ruttenberg wrote:
>Thanks for your comments Rob. It occurs to me that both the XML 
>Schema and the OWL working groups are in progress, that this is an 
>issue that touches both groups, that having the specifications be 
>able to be read in conjunction without confusion as to their 
>relationship would be beneficial to overall efforts of the W3C 
>towards harmonization and the implementors and users of those 
>specifications.
>
>Perhaps we can take advantage of the felicitous timing to ensure 
>that our respective specifications are consistent with each other by 
>ensuring that terms are used in the same way, if necessary adding 
>clarification, and by attempting to have any additional datatype 
>concepts needed for a good OWL specification be incorporated into 
>the XML Schema specification.

I'll leave comments on this aspect to others who are more up on precise
development/publication schedules.

>Towards the end of understanding the terminology, I've been trying 
>to understand what the value space of XML Schema means, given that 
>it doesn't mean what one would expect in a mathematical sense.

I'll have to take exception to that.  I'm sure it doesn't mean what you
would expect in a mathematical sense.  But it does very definitely mean
what I would expect in a mathematical sense.  (Credentials:  Phd, U.C.
Berkeley, 1965, primarily in Analysis and Foundations of Mathematics;
Assistant Professor of Mathematics and Computer Science, and Associate
Professor of Mathematics at various times during my career.)  So please
don't generalize to an arbitrary "one" and imply that that's the only
possible reasonable expectation.

>Similarly, there seems to be missing an underlying type for the date 
>types - although there is reference to timeOnTimeline, this value 
>type is not surfaced in the type hierarchy.

I'd very much like to hear how you'd do this; unlike the number datatypes,
where I could envisage how to pull them together, I can't envisage a
reasonable way for all the d/t datatypes to be derived from a universal
one.  And I did try.

>One thought is that whether a correct interpretation is more along 
>the lines of considering the value spaces as data structures.

I'm curious what you mean by "data structure" here.  Reading on, it sounds
like you mean various possible machine representations of the values.
Let me assure you that that's not what is meant by a value space.  In
fact, I can think of several extremely different-appearing representations
of, for example, the integers, that are nonetheless isomorphic.  They
are all potential machine representations of the values for the same
datatype.  XSD does not have anything to say about machine representations,
except to say that if an implementation has two different representations
of the same value, it is obligated to generally treat them the same.

>Another thought is that the value spaces are another aspect of 
>lexical expression. This would account well for there being a 
>difference between base64Binary and hexBinary, but not explain why 
>these are not pattern facet restrictions on string.

base64Binary and hexBinary are different because they use entirely different
lexical mappings.  Different lexical mappings mean different datatypes.
Except for our decision to paint the two value spaces different colors
so we can tell them apart, the value spaces of these two datatypes are
the same.  (In this case, I suspect that the obvious equality across
these two value spaces would not bother anyone.  But we weren't going
to do that for some obvious datatype pairs and not others.

They are not pattern-facet restrictions on string for the same reason that
float and double are not pattern-facet restrictions on string.  The value
spaces are different.  String values are character strings; the xxxBinary
values are bit-strings.  Bits aren't characters.

>Finally, I wonder if you have comments on a couple of other aspects 
>of datatypes that appear in XML schema. Specifically, data types 
>that are derived by list and time and date types. Clearly such 
>concepts or similar are relevant to OWL given work on, e.g. 
>workflow, or  in spatial reasoning. Where do they fit into your view 
>of OWL class space?

You both should definitely look up the latest Public Working Draft (a
Last Call draft) for XSD.  I think it might clear up some of the questions,
hopefully providing a better understanding or description of list
datatypes and date/time datatypes.
-- 
Dave Peterson
SGMLWorks!

davep@iit.edu

Received on Saturday, 5 July 2008 05:59:46 UTC