Lists Home |
Date Index |
- From: Frank Manola <email@example.com>
- To: firstname.lastname@example.org
- Date: Fri, 17 Apr 1998 11:52:15 -0400
At 8:55 PM -0700 4/16/98, Tim Bray wrote:
>At 10:35 PM 14/04/98 -0500, len bullard wrote:
>>> [Chris Maden <email@example.com>:]
>>> > One fundamental flaw in _XML Complete_ is Holzner's apparent belief
>>> > that you must write Java code in order to do anything useful with
>>> > XML.
>>Markup doesn't care. That's the beauty of it. :-
>Yes! What he said. As a result of having been a programmer since
>A.D. 1979, my faith in interoperable APIs is torn and shredded.
>But I think that interoperable syntax is usefully achievable.
>Hence, XML. -T.
and Matthew Gertner wrote:
>Eliot Kimber indicated some scepticism as to whether OO techniques have
>really lived up to their hype. In terms of a controlled environment, they
>have. Any C programmer who has moved onto C++ will attest that OO features
>make it far easier to write extensible and maintainable code. On the other
>hand, the promise that this would lead to interchangeable components that
>could be used anywhere has clearly been a flop. Why? For exactly the reason
>Tim mentioned in his mail: interoperable APIs never work. You can't
>interface with code and expect this interface to apply to any environment
>other than the one it was specifically designed for. This is the case
>whatever technology you are using (DLLs, Java, JavaBeans, Smalltalk, COM,
>CORBA, etc.). Hence XML.
These observations about the (at least so far) lack of success with truly
interoperable APIs are certainly true, and the potential of interoperable
syntax "feels" right, but I wonder to what extent we may be comparing
apples and oranges here. Specifically, what do we mean by "interoperable"?
Interoperable APIs are hard at least in part because an incredible amount
of semantics are (implicitly) built into a typical API (as is suggested by
Matthew's comment). Moreover, interoperable APIs are held to a "strict
accountability": the programs interacting through them must work without
either syntactic or semantic errors (and, with programs, these are
typically all bundled up). However, if programs must agree on the precise
meanings of tagged data in order to guarantee proper operation when
exchanging data (and what else does a fair understanding of "interoperable"
mean in this context?), won't the semantics that must be mutually
understood be (approximately) just as complex? And don't we then need to
consider the mechanism(s) for achieving *that* in our comparisons? After
all, it's not enough that the programs be "interoperable" in the sense that
they can each "operate" (e.g., read, parse, or even approximately get the
meaing) on the other's data; the operation must also be "correct" in a
fairly constrained sense. I have in mind all the problems large companies
are having merging data from different databases into data warehouses due
to sometimes subtle differences in semantics (e.g,, of what a "customer"
is), even when the data item names (corresponding to markup) are the same
(or, at least, fairly regular). I'm not, here, arguing *against* the idea
of interoperable syntax, but I am questioning how easy it will really be to
get the degree of "interoperability" we seem to be implicitly expecting.
Frank Manola www: http://www.objs.com
Object Services and Consulting, Inc. email: firstname.lastname@example.org
151 Tremont Street #22R voice: 617 426 9287
Boston, MA 02111
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)