W3C home > Mailing lists > Public > www-archive@w3.org > July 2002

Re: LC Issue 226 Resolution

From: Paul Prescod <paul@prescod.net>
Date: Wed, 17 Jul 2002 15:40:45 -0700
Message-ID: <3D35F26D.DC71D8BE@prescod.net>
To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
CC: Paul Denning <pauld@mitre.org>, www-archive@w3.org, moreau@crf.canon.fr, Martin Gudgin <mgudgin@microsoft.com>, Marc Hadley <marc.hadley@sun.com>

Henrik Frystyk Nielsen wrote:
> >I have not proposed any details of URI encoding. I am proposing
> >guidelines on the URI-to-resource mapping. Nevertheless, I would accept
> >text in the Primer.
> Have you seen the section in part 2 [1] that talks about how parameters
> that are used to identify resources should be part of the URI? This is
> entirely independent of the request method used (in HTTP-speak), just
> saying that parameters that in some sense identify a resource should
> when possible be part of the URI.

Okay, I agree with that section and agree that it is highly related to
my issue.

There is one important part I do not understand. Why is this "best
practice" under the title "RPC" in both the SOAP primer and the SOAP
Part 2? If you were using a pure document-style of interaction would not
the same best practice apply?

I believe that SOAP's definition of RPC is: "the exchange of messages
that map conveniently to definitions and invocations of method and
procedure calls in commonly used programming languages".

If so, why would proper use of URIs on the Web and in HTTP be tied to
RPC? As you know, many of us see disciplined HTTP usage as an
*alternative* to RPC!

Until I hear back, I consider this a bug, but my level of stridency on
the issue will depend upon the cost of fixing it. 

The primer, especially, seems quite easy to fix (at least technically, I
don't know about procedurally). Merely replace the word "RPC" with
"message" or "message exchanges" (or some more appropriate word of your
choice). "Conveying web-friendly message exchanges" and "There are many
instances where message exchanges are designed for uses which..."

If something like that were done I would not push for any changes to the
normative specification.

Also, the primer section is a little bit confusingly written in that it
seems as if 3.1.3 is entirely about "pure information retrieval"
applications until you get close to the end. If it is still possible to
do some re-arrangement that does not change the meaning then I would be
glad to propose alternate text.

Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/
Received on Wednesday, 17 July 2002 18:41:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:42:08 UTC