W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2002

RE: issue: optional parts in <message>?

From: Mike Deem <mikedeem@microsoft.com>
Date: Sat, 4 May 2002 21:33:57 -0700
Message-ID: <A84507FC48EA7B4B86323F4E82483F7E024BA745@red-msg-04.redmond.corp.microsoft.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, <www-ws-desc@w3.org>
Yes, I think a binding can be used to specify exactly how the message is put on the wire.

 

For example, the WSDL extension for DIME specifies that the content of elements with the base64Binary and hexBinary type may be put in separate DIME records in an unencoded form. SOAP encoded and document literal messages are handled differently.

 

In the case of SOAP encoded messages, binary data is always put in a sepearete DIME record and the element in the envelope has a href attribute that specifies the corresponding DIME record ID.

 

In the case of literal messages, the binary data is put in a separate DIME record and the element in the envelope has an ref:location attribute that specifies the corresponding DIME record ID. However, this happens ONLY if the schema allows for an ref:location attribute and does not specify a minimum content length. In other words, the message content is will always be schema valid.

 

  == Mike ==
 

	-----Original Message----- 
	From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] 
	Sent: Fri 5/3/2002 11:00 PM 
	To: www-ws-desc@w3.org 
	Cc: 
	Subject: Re: issue: optional parts in <message>?
	
	

	OK, thanks; that helps. Question:
	
	Does the restriction on base64 imply that this is going to be sent in
	XML as base64 encoded data? The abstract description obviously
	needs to be above the wire representation and hence should not pick
	any specific format (that's what the binding will do).
	
	Basically, there is no indication at the abstract level whether the
	image will be sent inline with the SOAP envelope, as an attachment
	or sent by reference by just sending the URI to it.
	
	Thanks,
	
	Sanjiva.
	
	----- Original Message -----
	From: "Mike Deem" <mikedeem@microsoft.com>
	To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>; "Jeffrey Schlimmer"
	<jeffsch@windows.microsoft.com>; <www-ws-desc@w3.org>
	Sent: Saturday, May 04, 2002 10:53 AM
	Subject: RE: issue: optional parts in <message>?
	
	
	> It could look like this:
	>
	>    <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>
	>
	>   == Mike ==
	>
	> -----Original Message-----
	> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
	> Sent: Fri 5/3/2002 6:49 PM
	> To: Mike Deem; Jeffrey Schlimmer; www-ws-desc@w3.org
	> Cc:
	> Subject: Re: issue: optional parts in <message>?
	>
	>
	>
	> "Mike Deem" <mikedeem@microsoft.com> writes:
	> > Sorry. I'll get those links fixed. [1] should work. See section 6.
	> >
	> > In any case, the idea is to use a mediaType annotation element in a
	> > restriction on a base64Binary or hexBinary base type. This annotation is
	> > used in the style of a facet to constrain the media type of the binary
	> > data.
	>
	> I know .. I've heard that from others before too. But not being an
	> XSD expert I'm not sure I see exactly how that would look. Can you
	> please write it down?
	>
	> FYI, here's what the 2-item message consisting of a string name and
	> an image (say a head xray) would like in WSDL 1.1:
	>
	>     <message name="medical-record">
	>         <part name="person-name" type="xsd:string"/>
	>         <part name="head-xray" mimeType="image/gif"/>
	>     </message>
	>
	> Sanjiva.
	>
	>
	>
	
	
Received on Sunday, 5 May 2002 00:34:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:20 GMT