[
Lists Home |
Date Index |
Thread Index
]
Okay, try again.
The observation that "using a single vendor solution reduces
interoperability problems" is not a new one. Neither is it terribly
interesting. .Net resolves a number of the impedance mismatches between
the types defined in XSDL part 2 and the .Net languages by fiat. That's
fine, if you're only going to use .Net. I could equally well create a
canonical mapping for Java, or Perl, or Lisp, but lacking ownership of
those languages, it's likely that someone else could define a canonical
mapping, with different nuances, which produced different, incompatible,
sometimes inoperable behavior. It is also likely that those neither of
those canonical mappings would fully interoperate with .Net, based as
they would be on different assumptions, and lacking the MS-internal
review that .Net language bindings presumably go through.
So, is it better to define a type in XML as something that can be
validated, or as something that maps to type A in language Z, type B in
language Y, type A again in language X, and type L in language O?
I submit that attempting to define XML types by mapping to a set of
native types in privileged languages is neither robust nor extensible.
It seems to me that, on the model of validation of structured types, it
is possible to define unstructured (simple) types by how they are
validated, and that that definition is interoperable.
Amy!
--
Amelia A. Lewis amyzing@talsever.com alicorn@mindspring.com
There's someone in my head, but it's not me.
-- Pink Floyd
This is a digitally signed message part
|
