Re: issue: optional parts in <message>?

"Roberto Chinnici" <roberto.chinnici@sun.com> writes:
> 
> Agreed, but given that operations are defined in terms of the
> messages they produce and consume, the introduction of a
> first-class notion of subdivisions of a message is somewhat
> artificial. For instance, why stop at one level?

Oh come on .. I don't buy that for a minute :-). Logically
we always talk about sending n things and getting back k things;
we don't go down inside each of the n and expand them out!

The idea of parts was to recognize that while the operation takes
a single message, it is actually taking a collection of things. 
Each thing (a part) represents a first-class thing it takes. So
for example, if an ordering operation takes a purchase order
document and a vcard document giving it information about where to
send the stuff to, then that operation takes 2 things. In your model,
I would be forced to model those two as a single document, which 
they are just not!

To me the top level breakup into a collection is not at all
artificial .. that's what it is totally. 

> > Shoving them all into a complexType would work, but I think you
> > have to agree that's not a first class representation of the
> > logical parts of the message. Also, one cannot obviously use
> > any old complex type - otherwise there will be another mapping
> > layer. So one would need to establish rules for the kinds of
> > complex types that are valid for the message replacement. For
> > example, if there are two parts, do we want to say that you can
> > write them in any combination of element/attribute:
> >     2 elements,
> >     1st an elem, 2nd an attribute
> >     1st an attr, 2nd an elem
> >     2 attr
> > Most probably not. So we would have to pick one of these
> > styles and mandate that the complexType of a message must
> > conform to that style. <message> is basically a first-class
> > syntax for that style.
> 
> I find the argument that there is already a language to describe
> complex, structured data (and it's called XML Schema...) to be
> quite powerful. And, of course, with type extensibility, we can

I also find that argument to be very powerful. However, I'm still
having trouble accepting a complexType as the collection as a
natural solution to the problem. As I said earlier, that approach
works, but its not the most natural solution (for me).

> allow for other type systems to be used. The way this data
> representation (an infoset) is mapped to on-the-wire messages
> is entirely left to the binding. I don't see any real problem with
> requiring that a binding know how to deal with an infoset, even
> if it includes having to deal with alternative descriptions such as
> the ones you list.

I think we're talking about different things now. Suppose that
I want to describe a simple function:
    string getQuote (string, date)
Then, to me, it doesn't seem like a good thing that one can 
describe the incoming message using any of the followign complex
types (using pseudo syntax):
    <complexType t1>
      <element s : string>
      <element d : date>
    </complexType>

    <complexType t2>
      <attribute s : string>
      <element d : date>
    </complexType>

    <complexType t3>
      <element s : string>
      <attribute : date>
    </complexType>

    <complexType t4>
      <attribute s : string>
      <attribute d : date>
    </complexType>

This type is not providing a schema for the wire representation-
its only trying to capture the fact that there are two things being
sent. Do you really want to allow multiple infosets for that too?

What does that gain? Right now its clear how one should describe 
this function in WSDL. With the proposed new approach there would 
be at least 4 different ways .. 

> > Secondly, the parts themselves may be of types that are not XML
> > Schema types. While XSD can be used for such cases, its again
> > a second class way to describe those. For example, if the type
> > is MIME image/gif, then the WSDL 1.1 part mechanism lets you say
> > that with something like <part name=p1 mimetype=image/gif/>.
> > That is, it records, in a first class manner, the fact that the
> > part is a MIME thing of a certain type.
> 
> This is a very good point, but couldn't the same thing be done
> with a MIME type system? After all, we need more than one level
> if we want to deal with parts which are of type multipart/related.
> I see a slippery slope here, where we try to add more and more
> concepts to a message until we reinvent XML Schema.

As I said in my note a bit ago, I am NOT in favor of extending
the message element's flexibility. I inserted that issue because
I've heard users ask for it (just like I've heard from users 
who don't like the existence of message at all).

> But in the end  a request message is just that, a message. Nothing
> prevents a stub generator from interpreting the infosets for request
> and response messages and come up with an RPC view of an
> operation, if it so wishes. Binding information is not needed at all,
> as long as the type system used to describe messages is unambiguous
> (as opposed to being reinterpreted in substantially different ways
> by different bindings).

I disagree: if you have a message who's complexType is say
purchaseOrder, you wouldn't want the RPC-style stub generator
to expand out the top level children of that element into 
different arguments would you? I don't think so .. rather you
would want the purchaseOrder schema to be mapped to a business
object in whatever the language you're in and to get a method
which had one of those as an argument. So you would have to 
know whether to expand the top level type or not. 

> > OK that's enough arguments for now .. gotta save more for
> > later ;-).
> 
> Can't wait to hear them!  ;-)

We have to exhaust these first ... ;-).

Sanjiva.

Received on Thursday, 2 May 2002 11:05:48 UTC