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