[
Lists Home |
Date Index |
Thread Index
]
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
|
