- From: Dan Connolly <connolly@w3.org>
- Date: Mon, 12 Nov 2001 10:41:38 -0600
- To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
- CC: phayes@ai.uwf.edu, w3c-rdfcore-wg@w3.org
"Peter F. Patel-Schneider" wrote: > > From: Dan Connolly <connolly@w3.org> > Subject: Re: DATATYPES: mental dump. > Date: Mon, 12 Nov 2001 09:36:05 -0600 > > > "Peter F. Patel-Schneider" wrote: > > [...] > > > [...] > > > > > > Regardless of the situation with respect to incompatibility with RDF, I > > > view incompatibility with XML > > > > I gather you mean XML Schema, not XML 1.0 itself... > > Actually both. If you don't have the XML Schema stuff below, you have > valid XML, I'm getting confused... do you mean "valid" in the sense of XML 1.0? A document has to include a DTD in order to be valid in that sense. > which, in my view, should be valid RDF-in-XML. If you want to > have datatypes, then you should have, again in my view, XML Schema > datatypes. I agree that RDF should use the XML Schema datatypes... i.e. the value spaces and corresponding lexical representations. But you're not suggesting we should use the XML Schema mechanisms to declare datatypes, are you? That involves using the XML schema complex types as part of RDF syntax. Surely not for RDF 1.0, no? > > > as a fatal problem with both these proposals. > > > I think that a scheme that is not compatible with > > > > > > [possibly some some xml schema stuff that may or may not type the 7 below] > > > <foo [possibly some xml schema stuff that may or may not type the 7 below]> > > > <bar [possibly some some xml schema stuff that may or may not > > > type the 7 below]> > > > 7 > > > </bar> > > > </foo> > > > > > > is a non-starter. > > > > Er.. that's an awfully high bar. To date, it hasn't been necessary > > to implement XML Schema in order to parse RDF. > > > > I think that any scheme that requires an RDF parser to include > > an XML Schema processor to be a non-starter. > > > > -- > > Dan Connolly, W3C http://www.w3.org/People/Connolly/ > > If you don't want to have datatypes, then you don't have to implement XML > Schema. If you do want datatypes, then you *shouldn't* have to implement > XML Schema, as you *should* be able to just use an existing XML Schema > implementation. XML Schema has lots of stuff in it. The only bit that the RDF Core WG needs to deal with is the primitive datatypes: the value spaces and the corresponding lexical spaces. Not the element typing mechanisms, derivation by extension/refinement, local element types, or any of that stuff. > (If you can't, then there is a very serious problem with > XML Schema!) Well, there's the issue that adding an XML schema implementation to an RDF parser would increase its size by about 10x. The RDF parser I work with is 570 lines of python; it's a straightfoward SAX module; it keeps a couple stacks of information, but it's not doing anything really hairy. An XML schema implementation written in python (i.e. using the same substrate) is 10 times as big: 4495 12498 149313 XMLSchema.py 1847 5894 59171 applyschema.py 139 303 3460 xpath.py 6481 18695 211944 total > In either case, I see no reason to implement an XML Schema > processor, but, of course, if you want to use XML Schema datatypes then > you certainly will need (possibly indirect) access to an XML Schema > processor. We don't need to use XML schema's mechanism of associating types with elements and attributes in order to use XML Schema datatypes. RDF has its own, very simple/constrained, syntax that works just fine. Er... it works fine in some cases... cases where the constrained syntax is acceptable. There's a whole other class of situations where the constraints that make RDF 1.0 syntax as simple and self-evident as it is aren't acceptable; for those, I expect we'll develop ways of parsing arbitrary XML as local formulas, using extra clues from XML Schemas or some such. But that's a completely separate problem from the one at hand. Today's problem is: let's standardize a vocabulary of scalar/primitive datatypes (integer/date/float/...) for use in RDF applications. > How can it be otherwise? See proposals X, S, and DC. (I prefer S.) -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Monday, 12 November 2001 11:42:25 UTC