[
Lists Home |
Date Index |
Thread Index
]
Actually, I think we're largely in agreement, although it seems I need
to learn to write more clearly :)
Yes, I want data types, but I want those data types to match the real
world, not the computer world. (I completely agree with Amy's points in
this regard.) My point was that the only thing you gain by data types
like those found in XML Schemas is an ability to automatically generate
classes, database schemas, etc. more easily, and that's not worth the
loss in interoperability. I think Eric Bohlman summed it up nicely when
he said:
"AFAICT, the only loss from this view is that you can't write an
application
that reads a schema and automatically generates the most efficient
possible programming-language class definitions for the data described
by that schema. But as has been alluded to before, you can't do that
anyway unless the primitive types available in the schema language
correspond exactly to
those in the programming language. And isn't this use of a schema just
another case of wanting the schema language to do everything including
washing the dishes? Wouldn't it make more sense to have another
language that would allow you to write specifications that a class
generator could use in conjunction with a schema, rather than requiring
all schema processors to do things that are only useful for class
generators?"
This corresponds quite nicely with your statement:
"Bottom line: if XML were given a smart, generic constraint mechanism,
rather than one working group's guess at a useful type libraries, then
not
only would your problem of data binding be solved as well, but you would
also gain much more "type safety" and interoperability."
-- Ron
Uche Ogbuji wrote:
>
> Ronald Bourret:
>
> > It's really a trade-off between interoperability and functionality. The
> > more specific your data types are, the better your uses of those data
> > types will be. For example, if you're generating Java classes from your
> > schema and you really want a certain property to be an int, you'll do
> > better having an int data type than a genericAnySizeInteger data type,
> > which you will have no choice but to map to a BigDecimal.
>
> I think this is the crux of my disagreement with your position (which I understand to be that of much of the static-types-in-XML supporters). Amy Lewis nailed it when she suggested that the proper way to think of data types is against the problem domain, not the implementation language. Worrying about how to faithfully reproduce, say, an unsigned int type interoperably is very backward when it is very likely that the equivalent value in your real world problem *truly* follows a constraint of 0 to 2^32.
>
> If your data binding says "number from 0 to 300000" (maybe the value in problem space is velocity in meters per second), then why would your Java program use a BigDecimal? (It so happens in this case that WXS can, in a very rough and ugly way, give you the needed capability for expression, but it cannot in the general case.)
>
> Of course, by just blithely declaring it "int", and even more blithely binding it to Java, you've just lost the most effective means of preventing someone from using a value of 300001, which is the sort of thing that makes space ships blow up (not int versus float distinctions).
>
> In my view, the sort of blind data binding encouraged by WXS types is the terror of interoperability, not the boon. Programmers tend to miss this because they generate the mapping using shiny GUIs, and imagine nothing could possibly be amiss.
>
> Bottom line: if XML were given a smart, generic constraint mechanism, rather than one working group's guess at a useful type libraries, then not only would your problem of data binding be solved as well, but you would also gain much more "type safety" and interoperability.
>
|
