Forgot to 'cc' xml-dist-app -Anish --
attached mail follows:
Noah, From a practical standpoint, if I wanted to send 1GB string, I would send this as an attachment. In which case, the SOAP Envelope would be small, would be sent as the first MIME part (if I am using something like Soap with Attachments) and the receiver would know whether the Envelope is well formed or not before the entire string is received. -Anish -- --- Original Message --- > > And the unknowable philosophical question is: > "before you see the end tag, > do you even have an Infoset in which to look for > an mU attribute?" I > don't think that either Infoset or SOAP says > much about this. I think > most SAX applications act as if you can start to > extract information from > a partially parsed document. So, I can see this > one either way. As a > practical matter I would side with Marc (as > opposed to Mark) on this. > > What worries me more is streaming > request/response, which may be a use > case that doesn't make the 80/20 cut. Let's say > I want to define an > "uppercase this string" service, which returns > some body string in > uppercase. If the string is 1GByte long, it > would be nice to stream the > response while the request is coming in, and > indeed deadlock avoidance may > require it. If the input later proves to be > not-well-formed, how do you > reflect the fault? That's the case that worry's > me more, at least > architecturally. It's probably less common in > practice. > > Indeed, this can also arise when you are just > generating a long response, > and then get in trouble at the application > level. I guess all we can do is > leave it to the application to invent its own > error protocol and put that > in the body. As far as SOAP is concerned, this > will probably look like > success. > > Maybe someone (ws-i.org?) should invent a > standard user-level element to > be put as the last child of the body in cases > where such > application-detected errors occur? SOAP > wouldn't know about it, but it > could at least become a widely-deployed > convention. > > > ------------------------------------------------------------------ > > Noah Mendelsohn > Voice: 1-617-693-4036 > IBM Corporation > Fax: 1-617-693-8676 > One Rogers Street > Cambridge, MA 02142 > > ------------------------------------------------------------------ > > > > > > > > > Marc Hadley <Marc.Hadley@Sun.COM> > Sent by: xml-dist-app-request@w3.org > 04/01/2003 02:05 PM > > > To: Mark Baker <mbaker@idokorro.com> > > cc: Noah Mendelsohn/Cambridge/IBM > <noah_mendelsohn@us.ibm.com>, > xml-dist-app@w3.org > Subject: Re: Streaming and > Well-Formedness > > > > On Tuesday, Apr 1, 2003, at 13:20 US/Eastern, > Mark Baker wrote: > > > > It's my understanding that you shouldn't be > chucking mU faults, or > > doing > > any processing for that matter, until the > envelope has been determined > > to > > be well formed. > > > I'm not sure the spec says that, in fact: > > "A message may contain or result in multiple > errors during processing. > Except where the order of detection is > specifically indicated (as in > 2.4 Understanding SOAP Header Blocks), a SOAP > node is at liberty to > reflect any single fault from the set of > possible faults prescribed for > the errors encountered. The selection of a fault > need not be predicated > on the application of the "MUST", "SHOULD" or > "MAY" keywords to the > generation of the fault, with the exception that > if one or more of the > prescribed faults is qualified with the "MUST" > keyword, then any one > fault from the set of possible faults MUST be > generated." > > So I think my service would be at liberty to > return a mustUnderstand > fault even if the envelope turned out to be not > well formed (provided > of course a mustUnderstand fault was also > appropriate) > > Marc. > > >> -----Original Message----- > >> From: Marc Hadley > [mailto:Marc.Hadley@Sun.COM] > >> Sent: Tuesday, April 01, 2003 9:49 AM > >> To: Noah Mendelsohn/Cambridge/IBM > >> Cc: xml-dist-app@w3.org > >> Subject: Re: Streaming and Well-Formedness > >> > >> > >> > >> I agree that there are cases where streaming > is difficult, but there > >> are some cases where streaming is useful. > E.g. a receiver can send a > >> mustUnderstand fault without waiting for the > (potentially large) body > >> of the incoming message to be completely > received. > >> > >> Regards, > >> Marc. > > > > > -- > Marc Hadley <marc.hadley@sun.com> > Web Technologies and Standards, Sun > Microsystems. > > > > >Received on Wednesday, 2 April 2003 12:51:09 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:14 GMT