Re: issue: optional parts in <message>?

Is it August already?? Everyone seems to have gone on vacation!!!

Let me try to get some discussion going ..

"Mike Deem" <mikedeem@microsoft.com> writes:
> I'm going to reverse my position on message/part to a certain extent.
> It is no more correct to use schema to describe the abstract "parts"
> of a message then it is to use message/part as "simple" substitute
> for describing the structure of a single logical "part".

WOW! I didn't think I was convincing anyone!! Anyway, I'm glad
you feel this way.

> The problem is that the complexity allowed by various permutations
> of the part element's element and type attributes and the SOAP
> binding's style and use attributes prevents the emergence of a
> single clear idea of what a "part" is. I believe that an overall
> simplification of type/element and style/use is the best way to
> address this problem.

I agree the combination of part type/element with the options for
use/style is very messy at best. I'm all for a simplification ..
as long as we keep necessary functionality.

> A brief sketch of such a simplification is shown below. These
> are just some initial thoughts and are not intended to be a
> complete proposal.
>
> <wsdl:definitions
>   xmlns:wxs="http://schemas.xmlsoap.org/wsdl/type/xml-schema"
>   ...>
>
>   <wsdl:types>
>     <xs:schema ...>
>
>       <xs:element name="MyHeader1">
>         ...
>       </xs:element>
>
>       <xs:element name="MyHeader2">
>         ...
>       </xs:element>
>
>       <xs:element name="MyBody">
>         <xs:complexType>
>           <xs:sequence>
>             <xs:element name="p1" .../>
>             <xs:element name="p2" .../>
>           </xs:sequence>
>         </xs:complexType>
>       </xs:element>

So if I was modeling an RPC thing, would I still be modeling it as
an element with elements in it? In which case you're still using
XSD for the parts of an operation as far as I'm concerned!

>
>     </xs:schema>
>   </wsdl:types>
>
>   <wsdl:message ...>
>     <wsdl:part name="a" wxs:element="ns:MyHeader1"/>
>     <wsdl:part name="b" wxs:element="ns:MyHeader2"/>
>     <wsdl:part name="c" wxs:element="ns:MyBody"/>
>   </wsdl:message>
>
>   <wsdl:portType .../>
>
>   <wsdl:binding ...>
>     <soap:binding .../>
>     <wsdl:operation ...>
>       <soap:operation .../>
>       <wsdl:input>
>         <soap:header
>           parts="a b"
>           format="http://schemas.xmlsoap.org/wsdl/format/literal/"/>
>         <soap:body
>           parts="c"
>           format="http://schemas.xmlsoap.org/wsdl/format/rpc-encoded/"/>
>       </wsdl:input>
>     </wsdl:operation>
>   </wsdl:binding>
>
> </wsdl:defaintions>
>
> The key points are:
>
> * The unqualified @type and @element on wsdl:part are gone.
> @xws:element is the only way to reference message content defined
> in schema. You can't reference types directly (types don't appear
> in messages, elements do). If you want to reference content

If you do that, then it will be impossible to bind a WSDL
abstract description containing xws:element to something
other than XML 1.0 serializations. We had a long discussion
about this during the F2F .. Glenn and Keith argued hard
that saying element= does not mean than an element had to
appear on the wire. I argued it does and they were going to
do some XSD homework and come back with info .. but haven't
heard anything yet.

> definitions that use a different type language, you define a
> qualified attribute specifically for that type language.

That would defeat a great advantage of the WSDL 1.1 model:
I can write ONE abstract description using XSD purely as an
abstract type specification syntax and then bind it to
totally different "wire" formats: SOAP, Java, whatever.

Your approach would say that the abstract description is
coupled to the "wire" format .. something that would eliminate
a lot of WSDL 1.1's abstractions.

I'm not even sure it works for SOAP! SOAP 1.2 is written in
terms of the infoset and not XML 1.0. As a result, its perfectly
legal to have say a Java serialization of SOAP 1.2 .. then no
XML 1.0 elements appear on the wire!! I believe that if you
use PSV element information items then the only legal serialization
is XML 1.0 elements. Some XSD expert needs to clarify this.

> * @style, @use and @encodingStyle(?) are replaced with @format of
> the type anyURI. An URI for the combinations of style/use/encodingStyle
> make sense would be defined. For example: document/literal would be ?
> ohttp://schemas.xmlsoap.org/wsdl/format/literal? and rpc/encoded
> with SOAP encoding would be ?ohttp://schemas.xmlsoap.org/wsdl/format/
> rpc-encoded?. A single @format attribute allows the universe of
> recognized formats to be expanded without inventing new attributes
> and avoids discussions about the meaning and value of things like
> document/encoded.

Its certainly possible to encode the combinations of
@style/@use/@encodingStyle into one string. However, if its just
encoding like that what does that buy us?

To me, style=doc vs rpc tells me clearly whether the SOAP engine
is responbile for creating the method element wrapper or not (not
for style=document and yes for style=rpc). Use=encoded vs literal
tells me whether to interpret the XSD (assuming part/type was used)
as a literal XSD for a specific serialization (i.e., as XML 1.0) or
as a type to be encoded in the rules of the encoding style attribute.

> * @format may appear only on the soap:body and soap:header elements
> and not the soap:operation or soap:binding elements. It applies to
> all the listed parts. If you want to apply different formats to
> different parts, you have to use multiple soap:body or soap:header
> elements. However, a given format may place restrictions on this.
> For example using the rpc/encoded format would require that only
> a single body part can be specified (I think this is what will be
> required for SOAP 1.2).
>
> * @namespace on soap:body is gone.
>
> * @message on soap:header is gone. Only the parts listed
> in the input/output message associated with the operation can be
> part of the message.

I have to think about these more if there are answers to the
previos problems.

I would love to simplify part @type/@element .. but it seems to me
that the only way to do that is to drop @element .. and move that
bit of info (how to go from type to element) to the bindings.

Bye,

Sanjiva.

Received on Wednesday, 15 May 2002 13:10:16 UTC