Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|
|||||||||
