RE: HTTP Methods

Ah.  Got it.  I don't see that as a shortcoming.  If an agent is
gathering service descriptions prior, e.g., to planning how to
assemble some adaptive choreography, then there would naturally
be a phase of gathering information, planning behavior, and the
using that information to execute the behavior.

-bryan

-----Original Message-----
From: Patrick.Stickler@nokia.com
To: BRYAN.B.THOMPSON@saic.com; www-tag-request@w3.org; jon@hackcraft.net
Cc: danny666@virgilio.it; joe@bitworking.org; www-tag@w3.org
Sent: 2/25/2004 10:32 PM
Subject: RE: HTTP Methods


Having to make two requests to get back (typically) the same amount
of information that a HEAD request would return is inefficient. It makes
SW agents "second class citizens" of the web because they have to do
twice as much work to get the information they need to function.

Furthermore, while there are some approaches that can work to accomplish
the equivalent behavior of MGET (albeit requiring multiple requests)
such
approaches break down when considering the behavior of MPUT, and 
MDELETE.

Regards,

Patrick

-----Original Message-----
From:	www-tag-request@w3.org on behalf of ext Thompson, Bryan B.
Sent:	Wed 2004-02-25 17:52
To:	Stickler Patrick (Nokia-TP-MSW/Tampere); 'www-tag-request@w3.org
'; 'ext Jon Hanna '
Cc:	'Danny Ayers '; 'Joe Gregorio '; 'www-tag@w3.org '
Subject:	RE: HTTP Methods



I do see an opportunity for a "well-known" HTTP method for descriptions.
However, what I like better is to use HEAD to recover a header, e.g.,
Service-Description-Uri, whose value is the URL of the service
description.

You can then negotiation the description content type separately.

-bryan

-----Original Message-----
From: www-tag-request@w3.org
To: ext Jon Hanna
Cc: Danny Ayers; Joe Gregorio; www-tag@w3.org
Sent: 2/25/2004 8:45 AM
Subject: Re: HTTP Methods



On Feb 25, 2004, at 15:28, ext Jon Hanna wrote:

>
> Quoting Patrick Stickler <patrick.stickler@nokia.com>:
>
>>
>>
>> On Feb 25, 2004, at 12:40, ext Jon Hanna wrote:
>>
>>>
>>> ... I remain unconvinced of the case
>>> for MGET.
>>
>> Can you demonstrate how the equivalent behavior can be
>> implemented using the existing methods without resulting
>> in either (a) multiple requests for each single logical
>> operation or (b) unintended side effects in the case of
>> misunderstanding between client and server, or (c) efficient
>> and explicit failure if the request is not understood?
>
> I'll qualify "unconvinced" as meaning "I've only looked at this a tiny

> bit, and
> it didn't convince me" as opposed to "I've looked at this a lot and I 
> think
> it's wrong". It's an uninformed instinct thing.
>
> That said, and given that URIQA is on my list of stuff I want to look 
> at in the
> near future (but I've been putting it off until after my current
paying
> project) why not GET application/rdf+xml rather than MGETting?

What if the resource denoted by the URI has an RDF/XML representation
yet you don't want the representation of the resource, you want its
description.

Content negotation is about selecting between representations.

While it might be possible to make it work for differentiating
between representations and descriptions, it precludes the ability
to select between different encodings of a description and also
(even if a special MIME type is used for descriptions) does not
make it possible to ask for descriptions of descriptions as opposed
to a representation of the description itself.

Patrick


> Granted an attempt to do so will result in most servers sending you 
> text/html or
> whatever and hoping for the best, but you can stop listening after the

> headers,
> it seems an explicit enough failure.
>
> -- 
> Jon Hanna
> <http://www.hackcraft.net/>
> "…it has been truly said that hackers have even more words for
> equipment failures than Yiddish has for obnoxious people." -
jargon.txt
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Thursday, 26 February 2004 06:13:26 UTC