Re: Streaming and Well-Formedness

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 Tuesday, 1 April 2003 14:24:43 UTC