Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] XML and OOP -- can this marriage be saved? (was Re: re: XMLSIG
 9/16/2002 4:46:49 AM, Sean McGrath <sean.mcgrath@p...> 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
