W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2002

RE: FW: LC Comments: Web Method Feature

From: Glen Daniels <gdaniels@macromedia.com>
Date: Sun, 7 Jul 2002 12:11:28 -0400
Message-ID: <CB1FF0A474AEA84EA0206D5B05F6A4CB0102C5DC@S1001EXM02.macromedia.com>
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

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.

Received on Sunday, 7 July 2002 12:12:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:51 UTC