[
Lists Home |
Date Index |
Thread Index
]
9/16/2002 4:46:49 AM, Sean McGrath <sean.mcgrath@propylon.com> wrote:
>
>Yes. There is, it seems to me, as potent a bifurcation between API-centric
>XML and notation-centric XML as there is between data heads
>and doc heads. There two are related, perhaps two sides of the same coin, I
>don't really have a handle on it but this article
>http://www.itworld.com/nl/xml_prac/04182002/
>gives a flavour of the itch I'm trying to scratch.
In that article, Sean says:
"The biggest conclusion I have come to is that APIs are fundamentally
good as shortcuts to getting your work done, but *only* if you fully
understand what is going on underneath. Using APIs as a substitute
for understanding what is really going on under the hood is a
bad idea which will come back to haunt you."
I can't decide if that's rank heresy or brilliant insight. :-)
The whole POINT of an API (well, an "interface" in OOP-ese) is to
encapsulate the details / hide the information that the user need
not be concerned with in order to use an "object". Maybe the HTTP
APIs that kept Sean away from his family were just poorly designed.
That is, maybe they simply didn't present powerful abstractions for
what's going on under the hood. Think of a "user interface" for a
car that exposed the choke and float in a traditional carbeuretor
and thus would force the driver to know whether the engine had
fuel injection or not. Would one blame the idea of having an abstract
interface and force all drivers to be technology geeks, or blame
the engineers who failed to come up with the abstraction of
an accelerator pedal as the user interface to the carburetor, fuel
injection unit, power supply for an electric vehicle, etc.?
On the other hand, there seems to be a persistent and growing
misalignment between the dogmas of OOP and the realities of XML
development. The WHOLE POINT of XML is to *break* the encapsulation
of data behind interface methods, thus allowing interoperability
at the data level rather than the object or API level. Of course,
specific applications can and probably should build abstractions
of the data so that their programmers can think of the XML as
"invoice" or "catalog entry" objects, but it's not at all clear that
the implementation of these objects would be well-served by being
abstracted away from the "under the hood" details of XML (and HTTP,
etc.). The RESTifarian mailing list was talking about a discipline
of Resource-Oriented Programming recently, and the most fundamental
split in many web services architectural discussions is over the
issue of whether reliability, orchestration, etc. are concepts that
can be hidden in the infrastructure as "services" or whether they
are simply the responsibility of the application layer.
I definitely agree with Sean that this is one of those "two sides of
the same coin" questions for which there is no universal answer. Some
people (most maybe) will deal with XML as simply an uninteresting
implementation detail of their distributed object system that SHOULD
be hidden away behind layers of APIs; others will need to open the hood
and tinker because the data itself is the most useful abstraction.
|
