W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2001

RE: [SOAP] soap question

From: Orchard, David <dorchard@jamcracker.com>
Date: Fri, 9 Feb 2001 02:51:16 -0500
Message-ID: <80B121FF56FDD411B0B100D0B7613B9D10E8@jx01.ummail.com>
To: Oisin Hurley <ohurley@iona.com>, dick@8760.com, XP-PUBLIC <xml-dist-app@w3.org>
Hi Oisin,

I think that we have a difference of opinion on what an object model needs
to be, and whether it is required for success or not.  Allow me to
illustrate.  XML as a spec was produced in 98.  It provided runtime syntax.
It did not need an object model (DOM?) API or an in memory model (infoset)
to be successful.  These things were required, but came later.  In the same
way, I would like the same for sending objects in SOAP.  I fully admit there
is an alternate approach, which is to define the algebra or object model
first, followed by the syntax.  Given the constraints on our WG's charter
and the syntax before it, the former approach of syntax first seems more

I don't understand your comment about using SOAP headers to pass "objects"
or blobs.   I could base64 encode all my binary objects, but that doesn't
meet the requirement of being able to attach an object without rewriting it.
This has been helpful as it has called out a requirement: It shall be
possible to send and receive non-xml information without requiring an XP
Processor to rewrite the outbound or inbound object.  

If you are uncomfortable with the term object to refer to some component
that has a structure semanticly and syntacticly opaque to XP, do you have an
alternate?  I find object to be sufficient, knowing that it does not meet
the classical O-O or COM definitions of objects.  Perhaps resource?


> -----Original Message-----
> From: Oisin Hurley [mailto:ohurley@iona.com]
> Sent: Thursday, February 01, 2001 12:20 AM
> To: Orchard, David; dick@8760.com; XP-PUBLIC
> Subject: RE: [SOAP] soap question
> > I, and many people I have talked to, would like the 
> scenario of sending
> > "objects" as part of or related to an XP message.  If that 
> then means that
> > the XP specification then has to do some work to define the
> > relationships -
> > addressing, encoding, by-value/by-reference - as a 
> framework for object
> > passing, so beit.  Nobody ever said our job was to do 
> trivial things.  We
> > could have just changed the SOAP namespace values to 
> w3.org/* and changed
> > the namespace identifiers from soapenv to xpenv.
> Hi David,
> What you are talking about here is serialization of objects 
> in a form that
> is
> valid for XP, i.e. as XML or perhaps as a binary attachment. 
> How we can
> do that without defining or referencing an object model is 
> strange territory
> to me. Maybe you want to define object references to pass around - how
> are you going to identify the object? How do you discover the 
> reference
> and what goes in there?
> > My guess is that standardized sending objects with XP is the
> > single biggest
> > requirement that people would like on top of SOAP.  Probably why
> > it was (one
> > of?) the first Note related to SOAP submitted to the W3C.
> Hmm. I can't say that this has been obvious from the f2f 
> interactions that
> I've been through.
> > I don't agree that we have to define an object model for XP.  We
> > can safely
> > leave the objects opaque.  We would have to define a mechanism for
> > referencing and/or containing an object model. There is a 
> Note before the
> > W3C on exactly how to do this, sans object model.  
> Therefore it is proven
> > that passing opaque objects can be defined without a defined
> > object model.
> You don't need an object model when you have 'opaque objects' because
> 'opaque objects' are just data blobs. An extension mechanism such
> as SOAP headers will allow you to pass blobs. This is fine, just don't
> call them 'objects' because that is a more semantically rich term!
>  --oh
Received on Friday, 9 February 2001 02:56:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:11 UTC