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.

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.  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.

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.


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 Tuesday, 4 February 2003 12:56:40 UTC