OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Sean McGrath hits a home run

[ Lists Home | Date Index | Thread Index ]

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS