Forwarded message 1
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.
>
>
>
>
>