RE: Proposal for the removal of the message construct from WSDL 1.2

> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] 
> Sent: 19 November 2002 16:55
> To: Martin Gudgin; WS-Desc WG (Public)
> Subject: Re: Proposal for the removal of the message 
> construct from WSDL 1.2
> 
> 
> Hi Gudge,
> 
> > Was discussed at FTF:
> > 
> > <xs:complexType name='foo'>
> >   <xs:sequence>
> >     <xs:element name='a' />
> >     <xs:element name='b' />
> >     <xs:element name='c' />
> >   </xs:sequence>
> > </xs:complexType>
> > 
> > <wsdl:input type='foo' />
> 
> What is 'foo' the type of though? Wouldn't it be the type
> of the SOAP:Body element? If so it conflicts with the
> already existing XSD type of SOAP:Body .. one wouldn't
> be able to validate with this for example. (Maybe I didn't 
> understand the answer.)

There is no problem ( to my mind at least ) validating a given element
against two different types.

> 
> > Alternatively use named model groups:
> > 
> > <xs:group name='foo'>
> >   <xs:sequence>
> >     <xs:element name='a' />
> >     <xs:element name='b' />
> >     <xs:element name='c' />
> >   </xs:sequence>
> > </xs:group>
> > 
> > <wsdl:input group='foo' />
> 
> Hmm. I don't know enough about groups to know what that would 
> mean .. does this amount to saying that the input can be 
> described as a type, element *or* group now? That seems to be 
> making things worse, not better.

No, we would only use group.

> 
> > soap:header already refers directly to element/type.
> 
> No, to a message. (?)

Err, no, to element/type. We made that change in Alex.

> 
> > Personally I'd model attachments using an element decl and 
> figure out 
> > the actual serialization in the binding.
> 
> How would that relate to the <wsdl:input type=> thing? Where 
> would it go I mean. Also, what would you put as the type of 
> the element decl?

Of the top of my head I'd probably use simple XPath to select the
element. Type of element decl could be any number of things. Most likely
in my head right now is a type that allows base64/hex as lexical form
but also allows attributes for reffing the 'attachment'

Gudge

Received on Tuesday, 19 November 2002 13:08:00 UTC