RE: issue: optional parts in <message>?

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

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>

Would be an optional alternative to this:

	<type>
		<schema ...>
			<complexType name="MyMessageType">
				...
			</complexType>
		</schema>
	</type>

	<message name="MyMessage">
		<part name="(any name)" type="sns:MyMessageType"/>
	</message>

	<portType ...>
		<operation ...>
			<input ... message="wns:MyMessage"/>
		</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.

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

Received on Tuesday, 7 May 2002 12:15:28 UTC