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

> -----Original Message-----
> From: John J. Barton [mailto:John_Barton@hpl.hp.com] 
> Sent: 04 February 2003 17:39
> 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
> 
> 
> Thanks, I think that these comments make your requirement 
> clearer.  It seems to me that what you want is for all the 
> data in a package to be "reachable" from the SOAP message by 
> XML defined means.  I think this is a reasonable requirement 
> but not one that can be formulated with the W3C infoset definition.

Oh, I think that qualified attributes would work just fine ( XInclude
uses qualified elements after all ).

> 
> We have an object--the SOAP XML--with some pointers inside. 
> Some of the pointers will resolve to entities in the package; 
> some will not.  As far as I can tell the infoset, being 
> designed without consideration of our case, treats all 
> pointers the same and it considers all referenced entities to 
> be outside of the infoset.  

The Infoset doesn't say anything about references. It knows nothing
about URIs. Therefore it knows nothing about 'referenced entities', not
even the fact that they exist.

> This is the only sensible answer 
> for normal hypertext documents. What you seem to want is a 
> "package-set" that has the properties of an infoset extended 
> to the pointers that resolve to within the package of data 
> sent with the SOAP.

Yes, I want some or all of the 'referenced entities' to actually appear
at the Infoset level. The infoset still doesn't know they were
'referenced entities'. As far as the infoset is concerned the data is
just inline.

> 
> I think the specification can obtain the properties you want 
> without the difficult approach of expanding the infoset 
> definition to cover a case it was not intended to solve.

I don't see why the definition of the Infoset needs to be expanded. The
current properties of the infoset are just fine. All we need to define
is how a given serialization maps to an Infoset, and I think that part
of that means having information items in the SOAP envelope to
facilitate that mapping.

Gudge

> 
> 
> At 03:08 AM 2/4/2003 -0800, Martin Gudgin wrote:
> 
> 
> 
> > > -----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
> 
> ______________________________________________________
> John J. Barton          email:  John_Barton@hpl.hp.com
> http://www.hpl.hp.com/personal/John_Barton/index.htm
> MS 1U-17  Hewlett-Packard Labs
> 1501 Page Mill Road              phone: (650)-236-2888
> Palo Alto CA  94304-1126         FAX:   (650)-857-5100
> 
>

Received on Wednesday, 5 February 2003 08:00:40 UTC