W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

RE: Issue 182: Fault Code restriction: "At Most One Fault Proposa l"

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Fri, 22 Feb 2002 10:09:08 -0000
Message-ID: <5E13A1874524D411A876006008CD059F1929AB@0-mail-1.hpl.hp.com>
To: "'noah_mendelsohn@us.ibm.com'" <noah_mendelsohn@us.ibm.com>, Henrik Frystyk Nielsen <henrikn@microsoft.com>
Cc: xml-dist-app@w3.org
Hi Noah,

So, I don't think I regard a mechanism that merely generates faults, or even
is we go so far as to say (in accordance with the resolution of Issue 102)
that an MEP spec. MUST detail the disposition of faults generated during the
operation of the MEP, provides us with a reliable mechanism to indicate

Even, if in all cases of failure we mandate the generation of a fault, I
think it would be a little unwise to *rely* on that as an "indication of
failure"... because there are no guarantees that it will be brought to the
attention of anyone/thing.



> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 21 February 2002 17:31
> To: Henrik Frystyk Nielsen
> Cc: Williams, Stuart; xml-dist-app@w3.org; xml-dist-app-request@w3.org
> Subject: RE: Issue 182: Fault Code restriction: "At Most One Fault
> Proposal"
> +1 (at least that's my initial reaction.)  Can't quite pin down why, but 
> I'm nervous about not being able to tell the difference between a request 
> that is proceeding successfully, but taking a seemingly unbounded amount 
> of time, but one which has silently failed.  Mandating that there is 
> always some indication of failure, as you propose, seems to deal with that

> concern.
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
Received on Friday, 22 February 2002 05:09:30 UTC

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