[
Lists Home |
Date Index |
Thread Index
]
Eric and Dare are both right here, depending on your perspective.
As I understand Eric, he wants to use the data types of the programming
language he uses or of the databases in which data is stored. Because these
systems already have well-defined types, any mismatch between their types
and the types of XML Schema get in the way.
As I understand Dare, he wants to be able to do "Native XML Programming",
using systems base directly on the built-in types of XML Schema. Most
databases and programming languages have a set of built-in types, and many
optimizations are based on knowledge of these types.
Actually, this is one of the real advantages of the facets approach taken
by XML Schema. You can define new types based on existing ones - if you
need an integer that can only be a certain size, you use facets to express
that. Any system that can handle the more general type can also handle the
specific one. But what if you want to specify new types that are not
derived from existing ones?
Many databases allow new types to be created with 'data blades' or
'extenders' or whatever. As Dare points out, this requires specification of
the operations on these types - how do you compare two instances? how do
you serialize an instance? how do you construct an instance from a
serialized format? I'm not convinced that MathML is the right language for
doing this, but such a language could be devised. However, the problem
turtles. The specification of these operations needs to be done in terms of
SOMETHING, which brings us back to the set of types known in the language
used for specifying the operations.
So what advantage would that have over doing it directly in W3C XML Schema?
Jonathan
|
