- From: Glen Daniels <gdaniels@macromedia.com>
- Date: Sun, 7 Jul 2002 12:11:28 -0400
- To: "'Paul Prescod'" <paul@prescod.net>
- Cc: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
Hi Paul! > [snip...] > > My point is just to clarify why the relationship between SOAP and HTTP > is very different than the relationship between HTTP and TCP > or TCP and > IP. HTTP is "top dog" because it defines the baseline semantics for > anything that builds on it, just as XHTML (or RSS or DocBook or...) > does. Great message. I think that analogy makes a lot of sense. So using your analogy, let's explore a little further: You add a "layer" above XHTML because you want to provide a meta-markup language to allow for a common set of tools and technologies to be built which can operate on the "meta-markup" despite the fact that sometimes it might serialize to XHTML and other times it might serialize to GIF and other times to PDF. Perhaps you have a "<section>" tag which resolves to either a "<p>" in XHTML, or a 15-pixel space in a GIF, or an equivalent (sorry, I don't know PDF internals at all :)) in PDF. Now you might find that there are some things you can express in the meta-markup that don't make sense to serialize as XHTML. That's OK, the tools and infrastructure would recognize that and the "binding" would disallow it. But you would take care when designing bindings to make sure that the specs correctly map the semantics of the meta- markup into the actual serializations without breaking any rules. There might also be some features of the underlying "presentation layer" (clearly not in the OSI sense here :)) which don't really exist in other bindings. For instance, you might be able to animate certain portions of a GIF-based presentation. Because the designers of our meta-markup framework thought about extensibility and flexibility, those "binding-specific" features could be expressed and exposed fairly easily for people/software who know that they are using a particular binding. However, for many features like this, you have the flexibility to design them in either very tightly technology-bound ways (e.g. the "GIF-animation" feature) *or* in more general ways which allow the semantic to be mapped to other (perhaps future) technologies as well (e.g. the "Animation" feature which can later also be bound to Flash when someone builds a Flash binding). To me, that's pretty much what SOAP (and the binding framework in particular) is about, much more than just trying to indiscriminately tunnel through widely-deployed technologies like HTTP by just using them as a pipe. SOAP has come to being in a world where there are a lot of internet technologies which are working well to do particular kinds of things. Just as HTTP took advantage of the TCP infrastructure which was already in place, SOAP wants to be able to take advantage of the variety of underlying protocols which are already deployed, but also to take into account their semantic differences. Perhaps this is too tall a goal, but for a protocol framework which already includes the notion of extending to enable arbitrary semantics, it just seems to make sense. So now let's imagine a world where you can either POST a purchase order to a website, or if you don't have a web browser, you can email the same purchase order to "orders@PaulCo.com", or perhaps if you pay to be on PaulCo's "inner circle" list, you can use MQSeries to drop a purchase order onto a high speed, reliable queue (perhaps with a guarantee of faster service). On the one hand, you might say "well, now that there are all these different ways to do this, interoperability goes down the drain". On the other hand, if we have a common high-level way of talking about what happens when a purchase order is processed, and perhaps even describing it in some WSDL-like form, I gain the ability to write software which deals with the high level, and allows the infrastructure/middleware to handle the actual bindings. This seems to me to be a good thing. Thanks, --Glen
Received on Sunday, 7 July 2002 12:12:01 UTC