Re: issue: optional parts in <message>?

Prasad Yendluri wrote:

> So much to catch up on in just couple of days.
>
> We seem to be having two (or more) separate discussions in this thread.
>
> 1. The original issue as stated in the subject: Can we have mark certain
> parts in a message optional.
> 2. If we need the message construct at all when the XML Schema can capture
> the entire message construct. I guess if this wins the first one resolves
> automatically :)
>
> On #2, I agree with many of the points made below. I think it is helpful
> and clean to be able model at the abstract level  input /output to
> operations comprising 'n' distinct parts irrespective their fundamental
> type and nature. IMO, XML Schema is too XML centric and using it model
> non-XML types is very unnatural. Additionally you want to be able to just
> drop in existing Schemas (RosettaNet, OAG etc.) rather than having to
> define XML-Schema wrappers for them and any associated entities such as
> attachments etc.

As a representative of Semantic Web work on services, I *strongly agree* with
the above statements.  One of the definite strengths of WSDL is its designed
ability to accommodate typing specifications from sources other than XML
Schema.  I'm involved in the work on DAML-S (DAML for Web Services), and
recently we decided to use WSDL to "ground" our service declarations.  It
turned out to be quite natural to specify a mapping between DAML-S service
inputs and outputs (whose types are declared in DAML) and WSDL message parts.
Thus it works out that there's a nice coupling between DAML-S and WSDL to
provide a complete service specification, but which doesn't rely on XML Schema
at all. If we had to define the entire input or output message of a DAML-S
service using XML Schema, this complementary use of DAML-S and WSDL would be
much more cumbersome (at best), and impossible (at worst).

Regarding #1, the ability to mark message parts as optional would certainly be
extremely useful in the context of this DAML-S/WSDL work.

Regards,
David Martin
SRI International


>
>
> Regards, Prasad
>
> 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.
> >
> > > > 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 Tuesday, 7 May 2002 00:48:08 UTC