Re: limits of the generic
At 01:33 PM 9/28/2002 +0100, Jeni Tennison wrote: > > How I long for a good honest integer. And I'm pretty sure Schema has > > lots more types than I will ever use. Still, it's a usable set of > > types, type extensibility was well designed, and it's being used by > > at least XML Schema, RELAX-NG, RDF, XQuery, XPath 2.0, and SQL/XML. > >It's hard to square "it's a usable set of types" with the fact that >XQuery and XPath 2.0 are changing that set: xs:integer in W3C XML >Schema is derived from xs:decimal; in the current WDs for XQuery and >XPath 2.0 it seems to be being treated as a primitive type of its own. I think that the way we handle integers is consistent with W3C XML Schema, which was not designed to define *operations* on types. We don't change the definition of integers, we simply define operations on them. >In W3C XML Schema, durations are covered by xs:duration; in the >current WDs for XQuery and XPath 2.0 you have to use either >xf:yearMonthDuration or xf:dayTimeDuration to get anything useful >done, even when a general duration would be completely unambiguous. Here I think we are dealing with a bug in W3C XML Schema - and perhaps one could argue that durations are less universal than integers, especially with respect to time zones. The most basic data types may also be the most useful. >If everyone could agree on a set of basic types then perhaps there >would be weight behind the argument that 1 *is a* integer and can >always be treated as such. The fact is that while isolated groups can >reach an internal consensus about what a data type means, we don't >seem to be able to get agreement between those groups. Given that, >doesn't it make more sense to say "this application *treats* 1 *as if >it were* an integer (as defined for that application)"? I think there *is* broad agreement for integers, floats, doubles, strings, etc. across programming languages and data representations. >At a document level, the same considerations apply. Just because a >document is valid against one particular schema does not preclude it >from being valid against another schema. Therefore the type of an >element is not an *essential* part of the element, but rather a >byproduct that's derived from using a particular schema with that >element. To me, processing the same XML text with two different schemas gives you two different documents. Other than that, I think our views are the same, or at least compatible. In order to build indexes for a document, I must know which schema was used to process it. >> If I take an integer out of a relational database and give it to a > > Java program, I would often like the Java program to know that it is > > an integer. Not just for one XML vocabulary, because I want to write > > tools that can handle more than one XML vocabulary. What's wrong > > with that? > >What's wrong with that is that you are tightly coupling your database >with your Java program. You are not only transferring the data, but >also dictating how that data should be interpreted. This means that >you tie your XML document into a particular use -- you're basically >using XML for *procedural* markup. Of course procedural markup can >give you many benefits, but it is not the only way of working. Hmmm....here's an area where we disagree. I think that a key benefit of data types is precisely that they are not procedural. They capture a small, abstract set of semantics which give the information needed for sensible general processing, like comparing two items or building an index. Jonathan
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format