[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: limits of the generic
Hi Jonathan, > As for XPath, I think that the *lack* of datatypes made XPath 1.0 do > an awful lot of guessing, and in an attempt to keep things simple, > it said that ALL numbers are floating point numbers. I don't think > that the lack of datatypes in the data XPath 1.0 used made things > simpler or more straightforward, it led to baroque rules for > guessing types. However baroque, it has to be said that the rules made XPath 1.0 very easy to use. It may seem baroque to implementers, who have to delve into the details, but to users XPath 1.0 appears to "just work". The same cannot be said of XPath 2.0. > 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. 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. 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)"? 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. For example, take the simple document: <cardno>1234567890123456</cardno> You could validate it against a schema that said that the cardno was an integer: <xs:element name="cardno" type="xs:integer" /> You could also validate it against a schema that said that the cardno was a string: <xs:element name="cardno" type="xs:string" /> '1234567890123456' is not, in and of itself, an integer or a string. We might want to treat it in either way depending on the depth of the validation and the kinds of processes that we want to carry out on the value. In an earlier email you wrote: > 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. To get the full benefit of interoperability and repurposing of your XML, it's better to use *descriptive* markup, where the application that receives the document can determine how it wants to treat it. Of course supporting descriptive markup is a lot harder problem than supporting procedural markup, but I don't think that this means we should ignore it. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
|
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
|