Re: issue: optional parts in <message>?

Mike Deem wrote:

> Exactly. For any realistic example, you end up with lots of schema and
> one part.

Unfortunately I have to disagree. In many realistic examples as in a
business process, one would need to put the payload (e.g. purchase-order) in
the context of the business process instance (and step). Hence there would
be a need to have a set of headers (schema) common to a few closely related
payloads. Like:

<message name="MyMessage1">
                <part name="header" type="headerNS:myHeaderType"/>
                <part name="payload" type="paloadNS:MyPOType"/>
</message>

With this at the binding (SOAP) level you need to be able to say the
"header" part goes into the SOAP-Env:Header and the "payload" part goes into
the SOAP-Env:Body etc.

> The MIME binding isn't a good counter example. In the realistic
> medical-record example, the gif content in the schema could be replaced
> with references (elements with the anyURI type), but the MIME binding
> would not be able to describe exactly what attachments must be included
> with the message or how those attachments relate to the message body.
> Only schema (or a schema like language) is expressive enough to do this.
>
> For the DIME extension, the message content as described by schema is
> the description of the attachments that are to be included in the
> message. We considered other approaches that used additional parts and a
> special attachment language or complex types in schema to describe
> attachment content explicitly, but these prevented a given message from
> being used by both a DIME and a non-DIME binding.
>
> In any case, I do agree that removing message/part is almost certainly
> not in scope for WSDL 1.2.
>
> However, I would like to propose that message descriptions be *expanded*
> to include constructs other then the wsdl:message element. Specifically,
> the message attribute on an input and output element would be able to
> reference a schema complex type directly. For example, this:
>
>         <type>
>                 <schema ...>
>                         <complexType name="MyMessageType">
>                                 ...
>                         </complexType>
>                 </schema>
>         </type>
>
>         <portType ...>
>                 <operation ...>
>                         <input ... message="sns:MyMessageType"/>
>                 </operation>
>         </portType>
>
> Such a mechanism would not be limited to just schema. Any type system
> understood by an implementation could be used to describe messages.

I think this would certainly a useful alternative if we can make some
adjustments to the binding syntax. The binding scheme is very much modeled
after the "header" "payload" (+other parts) format I listed above at this
point hence we have the

That is the reason we have the message=" and "part=" at the binding level,
as in:

    <input>
            <soap:header message="qname" part="nmtoken"
use="literal|encoded"
                                       encodingStyle="uri-list"?
namespace="uri"?>*
            <soap:body parts="nmtokens"? use="literal|encoded"?
                                       encodingStyle="uri-list"?
namespace="uri"?>
   </input>

Regards, Prasad

>   == Mike ==
>
> > -----Original Message-----
> > From: Jean-Jacques Moreau [mailto:moreau@crf.canon.fr]
> > Sent: Tuesday, May 07, 2002 7:06 AM
> > To: Mike Deem
> > Cc: Sanjiva Weerawarana; WS-Desc WG (Public)
> > Subject: Re: issue: optional parts in <message>?
> >
> > Another example would be the Purchase Order at [1]. The WSDL
> definition
> > would be:
> >
> >     <message name="purchase-order">
> >         <part name="purchaseOrder" type="tns:PurchaseOrderType"/>
> >     </message>
> >
> > but this is an oversimplification. In reality, the one liner above
> expands
> > into the 66 lines schema at [2]. I think you are questioning why we
> would
> > want to expose only the top of the iceberg (i.e. the top-level EIIs)
> via
> > the wsdl:part element. On that example, it might be more appropriate
> to
> > expose instead the 2nd level EIIs.
> >
> > Jean-Jacques.
> >
> > [1] http://www.w3.org/TR/xmlschema-0/#PO
> > [2] http://www.w3.org/TR/xmlschema-0/#POSchema
> >
> >
> > Mike Deem wrote:
> >
> > > I agree that the "pseudo-facet" syntax proposed in the WSDL
> extension
> > > for DIME is a bit verbose. However, I believe the advantages to be
> > > gained by using schema out weight working with the complex syntax.
> (I
> > > also think we can address most of the syntax issues in future
> versions
> > > of schema.)
> > >
> > > Using schema to describe content has the advantage that those
> > > descriptions can be shared across all levels of an application. For
> > > example, an XML store and the messaging layer would share the same
> > > schema for a "medical-record". I could simply pull a
> "medical-record"
> > > instance from the store and pass it to the messaging layer.
> > >
> > > Also, it isn't clear how a message/part representation deals with
> more
> > > complex content. For example, a more realistic version of the
> > > media-record schema would probably include multiple sets of images:
> > >
> > >         <xs:complexType name="medical-record">
> > >           <xs:sequence>
> > >             <xs:element name="person-name" type="xs:string"/>
> > >             <xs:element name="xray-set" maxOccurs="unbounded">
> > >               <xs:complexType>
> > >               <xs:sequence>
> > >                   <xs:element name="description" type="xs:string"/>
> > >                   <xs:element name="left-view" type="tns:gif"/>
> > >                   <xs:element name="right-view" type="xs:gif"/>
> > >               </xs:sequence>
> > >               </xs:complexType>
> > >             </xs:element>
> > >           </xs:sequence>
> > >         </xs:complexType>
> > >
> > > How would this be represented using message/part?
> > >
> > >   == Mike ==
> > >
> > > > -----Original Message-----
> > > > From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> > > > Sent: Monday, May 06, 2002 6:44 AM
> > > > To: WS-Desc WG (Public)
> > > > Subject: Re: issue: optional parts in <message>?
> > > >
> > > > Thanks Mike for showing exactly what non-XSD types being described
> in
> > > > XSD would look like. So it comes down to:
> > > >
> > > > > >    <xs:complexType name="medical-record">
> > > > > >     <xs:sequence>
> > > > > >      <xs:element name="person-name" type="xs:string"/>
> > > > > >      <xs:element name="head-xray" type="tns:gif"/>
> > > > > >     </xs:sequence>
> > > > > >    </xs:complexType>
> > > > > >
> > > > > >    <xs:simpleType name="gif">
> > > > > >     <xs:restriction base="xs:base64Binary">
> > > > > >      <xs:annotation>
> > > > > >       <xs:appinfo>
> > > > > >        <content:mediaType value="image/gif"/>
> > > > > >       </xs:appinfo>
> > > > > >      </xs:annotation>
> > > > > >     </xs:restriction>
> > > > > >    </xs:simpleType>
> > > >
> > > > vs.:
> > > >
> > > > > >     <message name="medical-record">
> > > > > >         <part name="person-name" type="xsd:string"/>
> > > > > >         <part name="head-xray" mimeType="image/gif"/>
> > > > > >     </message>
> > > >
> > > > I still maintain that the latter is a *much* more natural
> > > > way to express the statement that message consists of two
> > > > items, the patient's name and his xray.
> > > >
> > > > Sanjiva.
> > > >