Re: issue: optional parts in <message>?

Sanjiva Weerawarana wrote:

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

I agree that as a publisher/user of a service I often think in terms
of the "n things I send and the k things I get back", but that doesn't
mean that in the definition of a port type operation we have to expose
such a view. It seems to me that we could achieve all the goals of WSDL
even if we removed the concept of a message part. Fewer concepts
make not only for a simpler specification but also for one that constrains
its users a bit less.

By the way, I agree with what you said elsewhere, that this is more
of a 2.0 change.

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

So users/tools get to pick the one they prefer. The representations
you provide are different in other ways too. Are you using an
xsd:sequence or xsd:all compositor? Ultimately, it's the data
that matters, and that's well described by the infoset.

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

If the tool producing the WSDL cares about this, it can insert
an annotation specifying the intended RPC mapping. Similarly,
if the stub generator tool cares to honor the server's suggestions,
it can do that. Or perhaps the user of that tool has a better idea
for a mapping in mind. Why would you push RPC at the top level?

Roberto

--
Roberto Chinnici
Java and XML Software
Sun Microsystems, Inc.


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

Received on Tuesday, 7 May 2002 22:05:29 UTC