- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Tue, 21 May 2002 12:24:08 +0100
- To: "'Tim Bray'" <tbray@textuality.com>
- Cc: www-tag@w3.org, xml-dist-app@w3.org
Hi Tim, Hmmmm... my preference for the 'Content-Location' approach is because it works regardless of the style of SOAP message in use. The proposed URL-encoding approach works for some subset of SOAP messages that 1) fit the RPC conventions and 2) have only 'simple' parameter values. We could debate whether this hits a 60-40 or even 80-20 point - but unless we work on a URL encoding for almost arbitrary XML, there will be resource identifying SOAP messages that cannot be encoded into a URL. I'm not sure I buy what appears to be a "Current servers don't or can't generate Content-Location headers." argument. It may be true, but it does seem a little surprising. regards Stuart > -----Original Message----- > From: Tim Bray [mailto:tbray@textuality.com] > Sent: 20 May 2002 19:21 > To: Williams, Stuart > Cc: www-tag@w3.org; xml-dist-app@w3.org > Subject: Re: [WhenToUseGet-7] Re: TAG document: SOAP HTTP GET binding > avai lable > > > Williams, Stuart wrote: > > Hi Tim, > > > > Personnally, I prefer the Content-Location approach. > > On reflection, I think I disagree, and favor the URL-encoding > approach. > I agree the Content-location approach is slightly (but only slightly) > architecturally cleaner, but I want to go with URL-encoding for one > simple reason: Content-location requires that that extra implementation > work be done on the server side, whereas URL-encoding can be had for > free. Given the way the world works, the extra work just won't get done > most times, and the negative effect we're trying to avoid (the universe > of Web Services vanishes from URI-space forever) comes to pass. -Tim >
Received on Tuesday, 21 May 2002 07:24:27 UTC