First the nits:

* a more "RESTful" version of the xlink:href would expose the part as a
part of the path and not merely as a query expression. In other words,
I'd suggest replacing:

xlink:href="http://www.parts-depot.com/part?id=00345

with

xlink:href="http://www.parts-depot.com/part/00345

* Soap encoding tends to favor usage of the element content over
attributes. I'd suggest changing your example for getPartsListResponse
from:

<part id="00345">

to

<part-id>00345</part-id>

= = = =

The next point is a bit more subtle. I've tried to express it in a number
of different forums in a number of different ways, each time with little
success. I'm not going to try a bit of humor to see if it helps.

It is a bit ironic that a set of architectural practices under the title of
"Representation State Transfer" defines virtually nothing about the way in
which state is to be represented, and instead focuses on how Objects (or
more precisely, resources) are to be accessed.

Similarly, I find it a bit ironic that a protocol originally created as an
acronym for Simple Object Access Protocol specifies nothing about how an
object is to be accessed, but instead focuses pretty much exclusively on
how messages are to be represented. For more details on this subject, see
http://radio.weblogs.com/0101679/stories/2002/01/25/whatObjectDoesSoapAccess.htm\
l

It is very easy to come up with an example where one schema includes links
and other does not, associate the first with a URL and place the second in
an envelope and then portray this as a fundamental difference between SOAP
and REST. The truth is that HTTP nor SOAP require nor preclude "proper"
links.

Similarly, one can come up with an example where a resource is identified
based on query parameters in a URL and another in which a resource is
identified inside the body and portray this too as a fundamental
difference. This too is false as there are a number of SOAP toolkits which
will happily dispatch requests based on the URL. Furthermore, REST is an
architectural style - it does not dictate syntax. See
http://www.xent.com/pipermail/fork/2001-August/002941.html for more on this
topic, including the views of Roy Fielding on XML itself.

I will go a step further and indicate that it is possible to architect a
system in accordance to the principles of REST and then implement it using
SOAP. In other words, these two are compatible. I would argue that the
deeper issue is that SOAP does little to require such an architectural
style, in fact, most of the examples to date seem to espouse a different
architectural style. I discuss this further in
http://www.oreillynet.com/cs/weblog/view/wlg/1351#Analogy

= = = =

The reason I joined this mailing list, and have persisted, is that it is
my hope that some day a paper can be jointly authored which shows both SOAP
and REST in a positive light, shows the strengths of both, and how they can
be used in concert.

- Sam Ruby