David Forslund wrote:
> At 06:43 AM 10/2/2001 +1000, Thomas Beale wrote:
>
>
> >David W Forslund wrote:
> >
> >>Thomas Beale writes:
> >
> >>But this is not interoperability, as you describe it. Seems like a step
> >>backwards from current technology. You start with a language and then
> >>build an inteface from it?
> >Actually, that's very common. Consider what could happen with say the
CEN
> >or HL7v3 standards. They both include information models (not service
> >models), describing the required semantics for conformance. If one was
to
> >build a system from them, one could start with UML models, build >
software,
> >and export the API via .net. You might say: but why not use HDTF specs.
I
> >say, well you might (should that be "should"?), but some people might
not.
> But aren't you describing language specific interfaces not some higher
> level UML models? You are saying that the interfaces have language
> specific things in them, not abstract UML models. What am I missing
> here? I'm not referring to HDTF specs, here, but trying to understand
> what it means to generate an interface from a language specific
> system. This seems to be going from the particular to the general, not
> the other way around.
If I understand correctly, .NET has a tool which takes an IDL (or the IDL
embedded into an "executable," which is roughly the "exported symbol table"
of that executable) and produces "bindings" for a certain language. This is
similar, for example, to the Perl, Python, C++, Eiffel, et al. bindings to
underlying C routines in GNOME.
The upside is theoretical interoperability between language modules. The
downside is that a "least-common-denominator" approach may be necessary in
bridging the gap, and that language-specific features ("colloquial usage")
are lost in the translation.
