Re: Summing up on visibility(?)

Chris,

On Thu, Jan 09, 2003 at 04:57:54PM -0500, Christopher B Ferris wrote:
> Mark,
> 
> This started out with an example using POST. You promptly changed it to 
> PUT
> but none of this addressed the point I was attempting to make with POST.

I used PUT because it's easier to explain what it means than POST (I
speak from experience here, both as a learner, and a learnee 8-).  But I
wouldn't say POST is "more general"; GET, PUT, and POST are as general
as one another, but they each do different things.  There's zero overlap
between them.  So the principle is the *same* in those two cases, as it
would be for GET.

The simplest example I know to explain what POST means is;

  frame.add(dialog)

where POST means something very similar to "add" (except it's for data,
not objects).  See Walden's "known state" example earlier, as it may
help explain why POST can't do PUT things;

http://lists.w3.org/Archives/Public/www-ws-arch/2003Jan/0326

On to your example ...

You named two wrappers, "Review" and "Feedback".  I don't know exactly
what you meant by each of those (i.e. nouns or verbs), but given the
topic of discussion, I assume that "Review" is a verb.  So you might
use it like;

<envelope>
 <body>
  <m:review>
   [an-office11-document-goes-here]
  </m:review>
 </body>
</envelope>

This envelope now has a self-contained meaning, wouldn't you agree?
Everything you need to understand its application semantics (i.e.
"review this Office document") is right there.  That's the first sign
that you're not using POST semantics, because if you were, that envelope
would mean something different depending upon which method it was
transferred with; if it were sent with PUT, it would mean "store this
content", and the document wouldn't be reviewed.

The way I would request review of document with HTTP would be to just
POST the document to a URI that identifies a resource that reviews
stuff.

The hard part is obviously determining *which* URI to POST to.  This
requires a priori knowledge too, of course; the automaton has to know
what a "reviewer" resource is so that it can be informed that "this
URI identifies a reviewer".  Miles and I weren't able to agree that
this type of a priori knowledge is any different than the a priori
knowledge required to invoke a "review()" method, so I won't reopen that
one.  Suffice it to say that this is an alternate means of doing the
same thing, while respecting the uniform interface constraint.

As for "Feedback", since that's a noun, I'm not sure what you had in
mind by suggesting it.  Because it's a noun, then there is no problem
since no dispatch action is taken which would change the semantics of
the HTTP message.  My only issue with that example is that in most
cases, HTTP messages carry schmema instances, or compound schema
instances.  In other words, representations of resources or composite
resources, like a resumé, a set of resumés, or a resumé with an
embedded picture.  So I would expect "Feedback" would have a whole
schema available, rather than being a wrapper (unless it was a generic
wrapper, like you'd need for a set of resumés).  Maybe I'm making a
mountain of molehill over that, but I wasn't sure what you meant, and I
wanted to be comprehensive in my response.

Phew!  I hope that was helpful.

Cheers,

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Thursday, 9 January 2003 21:38:48 UTC