RE: issue: optional parts in <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. 
 
+1!

 -----Original Message----- 
 From: Roberto Chinnici [mailto:roberto.chinnici@sun.com] 
 Sent: Wed 5/1/2002 8:54 PM 
 To: Sanjiva Weerawarana 
 Cc: www-ws-desc@w3.org 
 Subject: Re: issue: optional parts in <message>?
 
 

 Sanjiva Weerawarana wrote:
 
 > I think the question is what the parts represent. Logically, the
 > parts of a message represent distinct items involved with that
 > operation.
 
 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?
 
 > 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
 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.
 
 > 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.
 
 > During the F2F Jeff asked a very good question: whether the only
 > things one ever cares to describe in WSDL are XSD types and MIME
 > types. I'm still not certain, but it certainly feels like those
 > are the common cases.
 >
 > Thirdly, the part/message concept is what made it possible to
 > unify both RPC style operations and document style operations
 > into the same abstraction. Doing away with message would mean
 > that if the operation is RPC style then the stub generator
 > should unwrap the outermost complexType into the different
 > arguments of the generated function while in the other case not.
 > How do you know which style an operation is when looking at
 > just the portType? You don't .. which means the signature of
 > a stub is dependent on the style of the operation; which is not
 > the case now. It basically breaks the unification of document
 > syle and rpc style operations that WSDL 1.1 achieves.
 
 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).
 
 > OK that's enough arguments for now .. gotta save more for
 > later ;-).
 
 Can't wait to hear them!  ;-)
 
 Roberto
 
 --
 Roberto Chinnici
 Java and XML Software
 Sun Microsystems, Inc.
 
 > Sanjiva.
 >
 > ----- Original Message -----
 > From: "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com>
 > To: <www-ws-desc@w3.org>
 > Sent: Thursday, May 02, 2002 7:47 AM
 > Subject: RE: issue: optional parts in <message>?
 >
 > > WSDL's goal is enable interoperable type descriptions; in the spirit of
 > > interop, types from 3g languages need to be represented in an
 > > interoperable format. For representational (data) types, the
 > > interoperable type system of record is XML Schema. For operational
 > > types, the interoperable type system of record is WSDL. It seems
 > > somewhat odd to only embrace one of these (WSDL) and not the other (XML
 > > Schema).
 > >
 > > The good news is that embracing both doesn't require unreasonable
 > > changes. Just as there will be adaptations you need to make to describe
 > > the operational types from your 3gl world in WSDL, there are comparable
 > > adaptations you should be making from the representational types to XML
 > > Schema. To use the WSDL message construct at a poor man's XML Schema
 > > language is pretty lame.
 > >
 > > --Jeff
 > >
 > > -----Original Message-----
 > > From: Grahame Grieve [mailto:grahame@kestral.com.au]
 > > Sent: Wednesday, May 01, 2002 5:26 PM
 > > To: www-ws-desc@w3.org
 > > Subject: RE: issue: optional parts in <message>?
 > >
 > > At 02:17 PM 01/05/2002 -0700, you wrote:
 > > >XML Schema provides a rich, well-understood language for expressing
 > > >choices, sequences, optional, repeated, etc. constructs. It does not
 > > >seem like a good use of the WG time to re-invent such a mechanism.
 > > >
 > > >Are there any interesting arguments against removing the message
 > > element
 > > >and making the operation within a port type point directly to an XML
 > > >Schema global element declaration?
 > >
 > > One common practice is to use WSDL as a representation of 3gl code
 > > and to interconvert between the 2. Using schema directly instead of
 > > the message parts structure in WSDL would encourage the use of data
 > > models that couldn't be treated this way and lead to calls for
 > > some mechanism to constrain the data model (such as "message parts")
 > >
 > > Of course, this same applies for most languages if the message parts
 > > acquire a cardinality option other than 0..1 and 1..1
 > >
 > > Grahame

Received on Thursday, 2 May 2002 01:32:26 UTC