W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2003

[Fwd: Re: Streaming and Well-Formedness]

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Wed, 02 Apr 2003 09:48:09 -0800
Message-ID: <3E8B2259.8080601@oracle.com>
To: xml-dist-app@w3.org
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