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