- From: Ugo Corda <UCorda@SeeBeyond.com>
- Date: Wed, 2 Jun 2004 22:56:38 -0700
- To: "Hugo Haas" <hugo@w3.org>
- Cc: "Herve Ruellan" <herve.ruellan@crf.canon.fr>, <www-ws-desc@w3.org>
Hi Hugo, This goes back to what I was asking during our previous meeting about WSDL and intermediaries. My understanding from the responses I received was that, in the presence of intermediaries, multiple WSDL files might be associated with the various segments of the message path. In other words, given a particular WSDL, it could very well be the case that the message submitter is an intermediary and not the message originator (and the message itself might not be in canonical lexical representation, as you mention below). Regards, Ugo > -----Original Message----- > From: Hugo Haas [mailto:hugo@w3.org] > Sent: Wednesday, June 02, 2004 10:23 PM > To: Ugo Corda > Cc: Herve Ruellan; www-ws-desc@w3.org > Subject: Re: Indicating element nodes that must be optimized with XOP > > > Hi Ugo. > > * Ugo Corda <UCorda@SeeBeyond.com> [2004-06-02 09:35-0700] > > I assume your response only applies to case 2. For case 1, > it would be > > unreasonable for the service provider to expect the element to be > > optimized. > > Maybe there is something I'm missing about case 1: can > certain base64 blobs not be be serialized in canonical lexical form? > > I had assumed that this limitation in XOP was only applying to > intermediaries: they may receive an element which is not in > canonical lexical representation; if their job was for > example to XOP-optimize the SOAP message, then they would not > be able to. > > However, for the message originator, I thought that it always > had the choice and therefore it was not a problem. If I am > designing my application and I have to use XOP, then I should > be able to do so. If I can't for some reason, then I should > not use a service that requires XOP-optimization of some things. > > Am I missing something? > > Regards, > > Hugo > > -- > Hugo Haas - W3C > mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ >
Received on Thursday, 3 June 2004 01:57:09 UTC