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.