RE: AFTF requirements, pre-2003/01/31 telcon

> -----Original Message-----
> From: John J. Barton [mailto:John_Barton@hpl.hp.com] 
> Sent: 04 February 2003 02:22
> To: Martin Gudgin; noah_mendelsohn@us.ibm.com
> Cc: jones@research.att.com; Rich Salz; Sanjiva Weerawarana; 
> xml-dist-app@w3.org
> Subject: RE: AFTF requirements, pre-2003/01/31 telcon
> 
> 
> At 03:26 PM 2/3/2003 -0800, Martin Gudgin wrote:
> >Well, I'm not certain that a synthetic infoset is EXACTLY 
> what I want, 
> >because, ideally, I'd like to be able to serialize my 
> infoset using XML 
> >1.0 + namespaces.
> 
> Ok then I am against your infoset requirement.  I don't 
> believe that XML will be able to do the job at this level.

I agree entirely that XML is not ideal for scenarios that include binary
information ( or other stuff that can't be easily contained in XML ).
But imagine I am an application. I construct an Infoset for a SOAP
message, including some large data, and I pass it to my SOAP layer. The
SOAP layer knows whether the guy at the other end understands SwA ( for
example ) and serializes the message accordingly. If the other end does
NOT understand SwA then the serialization is XML 1.0. Inefficient, yes!
But nevertheless workable. In cases where SwA is understood then we just
use SwA as the serialization.

> 
> >Not that I'd want to do that in the general case, because 
> one point of 
> >this exercise is to allow binary data and other stuff that 
> doesn't fit 
> >well into XML 1.0 serializations to be serialized efficiently...
> 
>   I hope the design aims for the general case since we 
> already have a solution for a single, short XML document. So 
> again the infoset can't be a requirement since it doesn't 
> apply to the general case.

I think you are equating Infoset with XML 1.0 serialization. I am
asserting that it is perfectly reasonable to serialize an infoset using
SwA ( again, for example ).

> 
> >But certainly the infoset you would get by parsing the SOAP 
> envelope, 
> >as is, is not the infoset I want.
> 
> Ok, so now I am complete confused.  

I'm sorry, it was not my intent to confuse. Let me try another example:

<m:Data xmlns:m='http://example.org/mystuff' >
  <xinc:include xmlns:xinc='http://www.w3.org/2001/XInclude' 
                href='http://example.org/somestuff/foo.txt' 
                parse='text' />
</m:Data>

How many Infosets does the above XML have? I think the answer is two,
one before you do XInclude processing, another after you've done
XInclude processing.

When I said 'The Infoset you would get by parsing the SOAP envelope as
is' I meant something akin to the before Xinclude example.


> The likely outcome from 
> the AFTF effort would be a specification that would lead to a 
> software component in a SOAP engine preceding XML parsing.  
> The component would pull bits off the wire and prepare them 
> for application level processing.  What the application 
> developer sees after XML parsing would be an object that 
> represents the wire data.  Such a developer would process 
> this object starting with the root of the SOAP message. As 
> one walked through the SOAP message some XML would be 
> processed and some of it would refer to other data, 
> attachments, by URI.  The API for processing the message 
> would seamlessly allow access to all of the data.

I think allowing the API to be Infoset based is useful, but it's not the
high-order bit for me. The important thing for me is that the SOAP 1.2
spec has defined an envelope and a processing model for that envelope.
That envelope is an Infoset. I want a way of applying that processing
model to whatever we end up producing in the AFTF. And I DO NOT want to
have to redefine that processing model in terms of the ancillary data,
for a variety of reasons.

> 
> Some of parts of this object would be an infoset; some parts 
> would not.   You
> don't want the part of the object that would be within the infoset 
> definition and
> you don't want the rest.  

I hope my XInclude example above shows what I do want.

> So I don't think you want what the 
> AFTF is trying to define!

The AFTF is defining an attachment feature to allow binary data ( or
other stuff that doesn't fit well into XML ) to travel with a SOAP
envelope. I'm just asking that for whatever serialization we come up
with, there be a mapping that gives me a single Infoset. I'm saying
nothing about streaming, order of processing, having to read the entire
envelope plus all ancillary data before returning to the app layer or
anything like that.

Gudge

Received on Tuesday, 4 February 2003 10:25:29 UTC