[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Sean McGrath hits a home run
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 inconvenient). 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 underneath. > 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
|
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
|