W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2001

RE: Draft Alternate Section 3.

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Mon, 26 Mar 2001 17:47:53 +0100
Message-ID: <5E13A1874524D411A876006008CD059F192343@0-mail-1.hpl.hp.com>
To: "'Krishna Sankar'" <ksankar@cisco.com>, "Williams, Stuart" <skw@hplb.hpl.hp.com>, "Henrik Frystyk Nielsen (E-mail)" <frystyk@microsoft.com>, "Jean-Jacques Moreau (E-mail)" <moreau@crf.canon.fr>, "John Ibbotson (E-mail)" <john_ibbotson@uk.ibm.com>, "Lynne Thompson (E-mail)" <Lynne.Thompson@unisys.com>, "Marc Hadley (E-mail)" <marc.hadley@uk.sun.com>, "Mark A. Jones (E-mail)" <jones@research.att.com>, "Martin Gudgin (E-mail)" <marting@develop.com>, "Nick Smilonich (E-mail)" <nick.smilonich@unisys.com>, "Oisin Hurley (E-mail)" <ohurley@iona.com>, "Scott Isaacson (E-mail)" <SISAACSON@novell.com>, "Yves Lafon (E-mail)" <ylafon@w3.org>
Cc: xml-dist-app@w3.org
Hi Krishna,

> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com]
> Sent: 26 March 2001 17:29
> Cc: xml-dist-app@w3.org
> Subject: RE: Draft Alternate Section 3.
> Stuart,
> 	As always, it is a pleasure discussing XML with you !
> 	Couple of points :
> 	1.	Message Sequence :
> 		Your discussion brings up a good point Chaining of XMLP
messages (within
> one Correlation.MessageRef). I agree that this goes beyond the SOAP/HTTP,
> but we should be looking at the future and secondly we might be using
> XMLP/SOAP/RMI or XMLP/SOAP/JINI or XMLP/SOAP/eSpeak or (of course)
> XMLP/SOAP/COM for all we care !

Sure... no argument, just a concern that it might need more careful thought
than I have given it so far.

> 		I was thinking of the web services space and using XMLP as
the basic
> protocol for web services.
> 	2.	I still have the question on [Faults]/ .status. If the
status is
> .failure, how do I know what happened ? Remember, there is no
> and so the app cannot ask for more details. May be the app would want to
> make decisions on the fault code or some similar information.

Ok... so this is different. From the senders point of view the lifetime of
the operation is from the .send to the .status.  These are implicitly
correlated. I could at a non-optional Correlate to the .status just to
emphasis this with a local abstract reference to the message that was sent.

If the status is failure, you may not know what has happened.  To be useful
failure should only be reported when the message definitely wasn't
delivered. It may not be possible to know how far down an intermediary chain
it got before failing. However, a subsequent fault-bearing message from,
say, the intermediary where failure occured *may* cast more light on the
problem - or may itself be lost!

> 	3.	I am actually thinking of prototyping this model as an
exercise and
> hence the detailed questions and concerns.

Sounds good... let me know how you get on.
> cheers


Received on Monday, 26 March 2001 11:49:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:12 UTC