Alex
Alex

Reputation: 9429

type or element in WSDL types section

It seems that I have some options when defining types in a wsdl <types/> section.

If I define a type (simple or complex) then I can reference that type like this: <message> <part name="x" type="tns:myTypeName"/>

If I define an element in the <types/> section as an <element/> then I can reference it like this: <message> <part name="x" element="myElementName"/>

Both options seem to pass validation. I have seen some examples with the element approach, but I don't see anything wrong with the type approach. Which one is correct?

Upvotes: 0

Views: 1344

Answers (2)

Alex
Alex

Reputation: 9429

Ok, I just found the answer. According to specification either one is an option. http://www.w3.org/TR/wsdl#_messages

It seems to imply that only one part is allowed if type is used. With element referencing many parts can be specified in the message. However, that doesn't seem to be the case. Reference John Saunder's post above for details.

Upvotes: 0

John Saunders
John Saunders

Reputation: 161773

Either one is an option, but they have different meanings.

If you use element, you're specifying the name, namespace, and type of the element in the message. If you're specifying type, then you are only specifying the type. In practice, then, the part in the WSDL message element specifies the name of the element, but the namespace is then ambiguous.

This is a frequent source of incompatibility. The WS-I BP 1.1 specification specifies to use element, not type, because this prevents the ambiguity.


I haven't read the WS-I BP 1.1 document for a few years now. I now remember that it's more complicated than I had recalled.

You must use type if you are creating an RPC/Literal service. You must use element if you are creating a Document/Literal service. There are restrictions on the use of namespace attributes in the WSDL in both cases, for the reason I specified: to prevent ambiguity.

See, among others, 4.7.21. Namespaces for Children of Part Accessors

One thing that's implied by the very existence of the WS-I: don't create a WSDL by hand, expecting schema validation to produce a valid service for you. Instead, use the tools provided by the web service framework you've chosen. This at least reduces the number of kinds of ambiguity you'll produce, to one set per framework.

Upvotes: 2

Related Questions