Assumptions about non-POST methods in Web description

[Mark Nottingham-2]

Most of the Web description proposals that I've seen model methods as  
discrete things in the context of a resource, e.g.,

<resource name='Example'>
   <method name="GET">
     <representation type="text/html">...</representation>
      ...
   </method>
   <method name="PUT">
     <representation type="text/html">...</representation>
      ...
   </method>
   <method name="POST">
     ...
   </method>
</resource>

I'm wondering if this is a good approach. While it makes sense to  
differentiate these things in code (because you need to glue the  
different methods to the implementation), it seems to me that non-
POST methods are special; they have fixed, well-known semantics and  
operate on the state of the resource.

Because of this, I'm wondering if it makes more sense to talk about  
the state of the resource as a first-order concept in the  
description, rather than operations on it (which don't need as much  
description); e.g.,

<resource name="Example">
   <representation type="text/html">
      <allow>GET PUT</allow>.
      ...
   </respresentation>
   <post>
      <input type="...">...</input>
      <output type="...">...</output>
   </post>
</resource>

That's just a straw man, I can see other formulations. The point is  
to encourage people NOT to think of this in terms of WSDL operations.

Thoughts?

--
Mark Nottingham     http://www.mnot.net/

[Jan Algermissen]

Hi Mark,

what is the intended consumer of this format?

Thanks.

Jan


On Mar 21, 2006, at 6:10 PM, Mark Nottingham wrote:

>
> Most of the Web description proposals that I've seen model methods  
> as discrete things in the context of a resource, e.g.,
>
> <resource name='Example'>
>   <method name="GET">
>     <representation type="text/html">...</representation>
>      ...
>   </method>
>   <method name="PUT">
>     <representation type="text/html">...</representation>
>      ...
>   </method>
>   <method name="POST">
>     ...
>   </method>
> </resource>
>
> I'm wondering if this is a good approach. While it makes sense to  
> differentiate these things in code (because you need to glue the  
> different methods to the implementation), it seems to me that non-
> POST methods are special; they have fixed, well-known semantics and  
> operate on the state of the resource.
>
> Because of this, I'm wondering if it makes more sense to talk about  
> the state of the resource as a first-order concept in the  
> description, rather than operations on it (which don't need as much  
> description); e.g.,
>
> <resource name="Example">
>   <representation type="text/html">
>      <allow>GET PUT</allow>.
>      ...
>   </respresentation>
>   <post>
>      <input type="...">...</input>
>      <output type="...">...</output>
>   </post>
> </resource>
>
> That's just a straw man, I can see other formulations. The point is  
> to encourage people NOT to think of this in terms of WSDL operations.
>
> Thoughts?
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>

________________________________________________________________________
_______________
Jan Algermissen, Consultant & Programmer                        
http://jalgermissen.com
Tugboat Consulting, 'Applying Web technology to enterprise IT'  
http://www.tugboat.de

[Mark Nottingham-2]

Hi Jan,

See: http://esw.w3.org/topic/WebDescriptionUseScenarios



On 2006/03/21, at 9:55 AM, Jan Algermissen wrote:

> Hi Mark,
>
> what is the intended consumer of this format?
>
> Thanks.
>
> Jan
>
>
> On Mar 21, 2006, at 6:10 PM, Mark Nottingham wrote:
>
>>
>> Most of the Web description proposals that I've seen model methods  
>> as discrete things in the context of a resource, e.g.,
>>
>> <resource name='Example'>
>>   <method name="GET">
>>     <representation type="text/html">...</representation>
>>      ...
>>   </method>
>>   <method name="PUT">
>>     <representation type="text/html">...</representation>
>>      ...
>>   </method>
>>   <method name="POST">
>>     ...
>>   </method>
>> </resource>
>>
>> I'm wondering if this is a good approach. While it makes sense to  
>> differentiate these things in code (because you need to glue the  
>> different methods to the implementation), it seems to me that non-
>> POST methods are special; they have fixed, well-known semantics  
>> and operate on the state of the resource.
>>
>> Because of this, I'm wondering if it makes more sense to talk  
>> about the state of the resource as a first-order concept in the  
>> description, rather than operations on it (which don't need as  
>> much description); e.g.,
>>
>> <resource name="Example">
>>   <representation type="text/html">
>>      <allow>GET PUT</allow>.
>>      ...
>>   </respresentation>
>>   <post>
>>      <input type="...">...</input>
>>      <output type="...">...</output>
>>   </post>
>> </resource>
>>
>> That's just a straw man, I can see other formulations. The point  
>> is to encourage people NOT to think of this in terms of WSDL  
>> operations.
>>
>> Thoughts?
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>>
>
> ______________________________________________________________________
> _________________
> Jan Algermissen, Consultant & Programmer                        
> http://jalgermissen.com
> Tugboat Consulting, 'Applying Web technology to enterprise IT'  
> http://www.tugboat.de
>
>
>
>
>

--
Mark Nottingham     http://www.mnot.net/

[Marc Hadley]

On Mar 21, 2006, at 12:10 PM, Mark Nottingham wrote:

>
> Because of this, I'm wondering if it makes more sense to talk about  
> the state of the resource as a first-order concept in the  
> description, rather than operations on it (which don't need as much  
> description); e.g.,
>
> <resource name="Example">
>   <representation type="text/html">
>      <allow>GET PUT</allow>.
>      ...
>   </respresentation>
>   <post>
>      <input type="...">...</input>
>      <output type="...">...</output>
>   </post>
> </resource>
>
> That's just a straw man, I can see other formulations. The point is  
> to encourage people NOT to think of this in terms of WSDL operations.
>

I think there could be cases where different combinations of  
representation format and method are allowed/supported where grouping  
of everything except POST might result in a lack of expressivity. I  
suppose you could allow the representation element to repeat to cover  
those cases if they are in the minority.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.

[Mark Nottingham-4]

On 2006/03/21, at 10:24 AM, Marc Hadley wrote:
> I think there could be cases where different combinations of  
> representation format and method are allowed/supported where  
> grouping of everything except POST might result in a lack of  
> expressivity. I suppose you could allow the representation element  
> to repeat to cover those cases if they are in the minority.

Yeah. It's a trade-off; I can see some situations where metadata  
(e.g., ACLs) will be asymmetric per method, and will therefore need  
to include that; e.g.,

<representation type="text/html">
   <acl method="GET" realm="readers"/>
   <acl method="PUT DELETE" realms= "readers writers"/>
</representation>

It's really just a different serialisation of the same data, the  
question is which communicates most clearly and which is easiest to  
use (two goals that are often at odds).

BTW, speaking of ACLs, an interesting reference is the WebDAV ACL spec;
   http://www.ietf.org/rfc/rfc3744

It would be nice if a Web description format could easily  
interoperate with them (although I'm not terribly fond of the model;  
why didn't they just put ACLs directly on HTTP methods?)

--
Mark Nottingham
mnot@...

[distobj]

On 3/21/06, Mark Nottingham <mnot@...> wrote:
> That's just a straw man, I can see other formulations. The point is
> to encourage people NOT to think of this in terms of WSDL operations.

+1!  I used this approach for RDF Forms.  For example, one can use it
to declare;

<rf:Container rdf:about="some-uri"/>

which means "the resource identified by that URI is a Container",
where Containers are defined by the spec to be resources to which data
can be submitted, like HTTP POST, NNTP POST, SMTP DATA, XMPP message,
etc... Similarly;

<rf:Settable rdf:about="some-uri"/>

says that the resource's state can be set explicitly, ala HTTP PUT,
FTP STOR, etc..

On the other hand, I don't know why POST is special from this POV.
It's the "catch all" semantic for tunneling, but outside of that, has
as well-defined and general a meaning as any other operation...  which
is by far the most predominant use of POST; HTML forms.

Mark.
--
Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca