OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Data binding as type definition

[ 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.

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS