RE: [SOAP] soap question

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

Of course :) This is because XML is a markup language, not an
invocable entity.

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

I think you will have to change the term that you use - an object is a very
well-defined programming entity that has certain properties and facilities.
Maybe you wish to create a syntax that will impose an object model.
I think what you think is an object and what I think is an object are two
different things.

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

I don't know what this means. How do you rewrite an object? Do you mean that
it is serialized or marshalled in some way?

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

That's in the requirements document for extensibility.

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

Whatever you wish :) But do not call it an object - terminology is there to
assure precision, not confuse.

 cheers
   --oh

Received on Friday, 16 February 2001 16:23:57 UTC