From: Joseph Coffman ([email protected])
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 <[email protected]>; 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$[email protected]> >From: "Jonathan Borden" <[email protected]> >To: "Peter F. Patel-Schneider" <[email protected]>, > "Pat Hayes" <[email protected]> >Cc: <[email protected]>, <[email protected]> >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: ><[email protected]> ><[email protected]> ><p05101025b82c5d12544b@[65.212.118.149]> ><[email protected]> ><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