[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Sean McGrath hits a home run

mcgrath protocol
Mike Champion wrote:

> But especially with committee-written standards (and I think this
> reflects the points in Daniel Veillard's post) there may simply be no
> coherent abstraction that can be cleanly encapsulated.  I don't know
> enough about HTTP to have an opinion if the APIs are merely bad, or if
> they reflect an unpleasant reality about the conceptual integrity of 
> the  underlying protocol.  (I would tend toward the former).  But with 
> XML,  having spent quite a bit more of my life that I will probably 
> care to  admit on Judgement Day working on APIs for it, I think it's 
> hard to  argue that there is a clean abstraction that can be exposed 
> with APIs  and implementations can be hidden behind.  

Maybe the problem isn't with either the APIs or the protocols/formats. I 
propose that one must choose: either the API is primary or the 
protocol/format is primary. If you decide the API is primary then the 
wire format will tend to be pretty ugly and hard to decipher. It will 
probably tend to degrade over time because it "doesn't matter much." Try 
decoding IIOP ... or, increasingly, SOAP to see this phenomenon in action.

Alternatively you can decide that the wire format is primary and the 
programmer abstraction is secondary. Then it will be hard to make a 
programmer abstraction that "feels right". The syntactic shortcuts you 
use like entities and qnames will become quite inconvenient at the API 
level. XML Schema is actually pretty API hostile (like most XML schema 
languages) because it allows the description of languages which are nice 
to look at, read and type, but have no obvious or natural mapping into 
programming language data structures (other than the DOM, which is 

I believe that it is impossible to optimize *both* API and data 
representation/protocol. Sean had problems with the APIs becuse the 
API's authors did not understand that it was their responsibility to as 
closely as possible emulate the capabilities of the wire format. APIs 
should abstract over APIs. Wire formats should abstract over wire 
formats. But APIs should not abstract over wire formats. They should 
offer as close a fidelity as is possible to what is actually going on 

> Seems like a rehash of Joel Spolsky's Leaky Abstractions article with
> different examples. What did you find outstanding about it?

The thing I think Sean is getting at, (which is different than the thing 
Joel Spolsky said) is: "If you are working with something that is 
primarily a data format or wire protocol, understand the data format, 
not an API abstraction of it. The API will only ever be a poor 
reflection of it. If you are working for something that is defined 
primarily as an API, understand the API and ignore the data/wire format. 
The data/wire format is at best a debugging tool."

As Sean says: "Top amongst my doubts about APIs for things like HTTP is 
that HTTP, when all is said and done, is a document exchange protocol."

  Paul Prescod


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.