Fwd: member submission from ["Jonathan Borden" <jborden@mediaone.net>]

From: Joseph Coffman (jcoffman@bbn.com)
Date: 12/04/01


> >From majordomo-owner Tue Dec  4 08:26:41 2001
>Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144])
>         by mail.daml.org (8.10.2+Sun/8.10.2) with ESMTP id fB4DQfi00674
>         for <joint-committee@daml.org>; Tue, 4 Dec 2001 08:26:41 -0500 (EST)
>Received: from [204.17.79.89] (host89.17.79.204.lifespan.org [204.17.79.89])
>         by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id fB4DNlQ09350;
>         Tue, 4 Dec 2001 08:23:47 -0500 (EST)
>Message-ID: <01a201c17cc6$c21fb030$0a2e249b@nemc.org>
>From: "Jonathan Borden" <jborden@mediaone.net>
>To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>,
>    "Pat Hayes" <phayes@ai.uwf.edu>
>Cc: <www-rdf-interest@w3.org>, <joint-committee@daml.org>
>Received: from synapse.nsur.nemc.org by [204.17.79.89]
>           via smtpd (for chmls06.mediaone.net [24.147.1.144]) with SMTP; 
> 4 Dec 2001 13:23:03 UT
>References: 
><A03E60B17132A84F9B4BB5EEDE57957B162282@trebe006.NOE.Nokia.com> 
><20011129084927P.pfps@research.bell-labs.com> 
><p05101025b82c5d12544b@[65.212.118.149]> 
><20011130120949I.pfps@research.bell-labs.com> 
><p0510100eb832156171da@[169.254.199.144]>
>Subject: Re: Cutting the Patrician datatype knot
>Date: Tue, 4 Dec 2001 08:22:37 -0500
>MIME-Version: 1.0
>Content-Type: text/plain;
>         charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook Express 5.50.4807.1700
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
>
>Pat Hayes wrote:
>
> > >
> > >[...]
> > >
> > >>  OK, but now what is the problem with my MT extension, again? Of
> > >>  course, with THIS sense of "union", one cannot treat [integer union
> > >>  string] as in any sense the simple class-union of the classes
> > >>  [integer] and [string]. So as far as the RDF reasoner is concerned,
> > >>  [integer union string] is just another datatype, which might as well
> > >>  be called [foodle]. If someone were to assert that
> > >>
> > >>  [integer] rdfs:subClassOf [integer union string] .
> > >>
> > >>  that would be correct, but that would cause no problem in the MT,
> > >>  since [integer union string] agrees with [integer] on numerals; they
> > >>  have the same lexical-to-value mapping on anything that would map to
> > >>  an integer. Similarly, it would be correct to assert
> > >>
> > >>  [string] rdfs:subClassOf [string union integer] .
> > >>
> > >>  though in that case it seems rather pointless since in this case the
> > >>  datatypes are identical, since even numerals will be mapped as
> > >>  strings by that union. But again, this poses no problems for the MT.
> > >>  On the other hand, if someone were to assert
> > >>
> > >>  [string] rdfs:subClassOf [integer union string] .
> > >>
> > >>  then that would be simply false, as all numeral strings are in the
> > >>  former value space but not the latter.
> > >
> > >I don't see how this follows.  The value space of the XML Schema datatype
> > >[integer union string] is precisely the union of the value spaces of
> > >integer and string.
> >
> > Yes, Ive come to see that. I simply did not conceive that anything
> > could be this badly defined. This aspect of XML datatypes really is a
> > crock. It *defines* the domain and range of the datatyping functions
> > so that they cannot possibly be the real domains and ranges. What a
> > bloody silly thing to do, I'm amazed that Thompson put his name on it.
>
>It should be noted that:
>
>a) Henry was not the editor of the XML Schema datatypes spec
>b). I can't say that I've thought it through in extruciating detail but my
>gut instinct would be, given that XML is ultimately a _text_ format, to
>derive all types, including simple types, not from the _value space_ but
>from the _lexical space_. (this distinction is made in XML Schema
>datatypes). The reason to have a distinct value space is to provide binary
>datatypes (e.g. integers that fit into 32 bits) and to ease the definition
>of comparison operators that operate on numbers (as opposed to patterns of
>characters). It seems to me that one could (simply?) define number
>comparison operators (it seems that mathematicians had gotten along
>reasonably well before the advent of 32 bit integers and 64 bit floating
>point math coprocessors), in the same way that one defines lexical
>comparison operators for such things as string sorting, ditto for dates etc.
>c) simple types such as "integer" "float" etc have been defined long ago and
>will be defined in the future (i.e. this is not the sole domain of XML
>Schema datatypes).
>d) there are (currently) _serious_ problems assigning URIs to general XML
>Schema datatypes. The URIs given for the simple XML Schema datatypes have
>been explicitly created. The XML Schema formalism (WD) proposes a new URI
>syntax to resolve these issues, but this syntax is not comparible with other
>XML fragment identifier syntax proposals including XPointer. Sigh.
>
> >
> > So, my argument does not hold if we are obliged to conform to XML
> > datatyping rules. I am inclined to just give up and leave this
> > decision to others, at this point. There is no point trying to be
> > rational when one is obliged by mandate to conform to irrationality.
> > Let me know what y'all decide.
> >
>
>I agree but should mention that these are _XML Schema 1.0_ datatyping rules,
>not _XML_ datatyping rules (that is to say that many in the greater XML
>community feel that the last word on _XML_ datatypes has yet to be written).
>XML 1.0 itself has a barebones discussion of element types (which are merely
>element tag names) and attribute types (e.g. CDATA,ID,IDREF and tokens). My
>suspicion is that if this group attempts to adopt XML Schema datatypes en
>bloc, that such problems will continue to plague these discussions for a
>long time.
>
>Jonathan


This archive was generated by hypermail 2.1.4 : 04/02/02 EST