Re: Basic Profile

Josh,

The namespace specified in the <soap:body> element (in the <wsdl:binding> 
definition) determines the namespace for the RPC wrapper element (the 
immediate child of the <soap:body>). The specs don't indicate what 
namespace should be used for the child elements of this RPC wrapper 
elements (the parameter and return value elements). The fact that this 
information hasn't been specified is definitely a source of 
interoperability problems, hence WS-I has defined a constraint for this issue.

Since these elements are only relevant within the context of the RPC 
wrapper element, it makes sense to define them as local elements of the 
generated RPC wrapper element. If you qualify them with a namespace, then 
you are implying that they are global elements and they are relevant 
outside of the context of the RPC wrapper element.

In terms of your suggested options:
1. make it illegal.
Make what illegal? RPC/Literal? Actually, I think that's a great idea. I 
don't see how RPC/Literal provides any advantage over Document/Literal, and 
the fact that you have no schema for the wire format is a significant 
disadvantage. But there was a lot of resistance in the group to making the 
RPC style illegal. (I can't think what else you might be suggesting be made 
illegal -- if you are using RPC style, the SOAP runtime must generate 
elements without a schema definition, so we need some guidance on how to 
namespace qualify these elements.)

2. use the binding to define the namespace.
Are you saying that you want to add a <soap:part> element for each message 
part to the <soap:binding> definition? Or that you should use the namespace 
defined in the <soap:body> (which defines the namespace for the RPC wrapper 
element)  to qualify each of the parameters. I don't like the first option 
(way too much work -- and it requires a change to the spec). The second 
option is a reasonable alternative to the decision made, except that these 
elements have no meaning except as parameters of the RPC wrapper element, 
so IMHO it makes more sense to treat them as local elements of the RPC 
wrapper element.

3. use the WSDL targetNamespace:
This seems a bit arbitrary. These elements are not defined in the WSDL 
definition, and the SOAP message may not necessarily use the WSDL 
targetNamespace for any other element.

4. use the type namespace:
IMHO this option isn't as reasonable as #2-b. The type may be used in any 
number of messages, and you do indicate the type namespace when you declare 
the type (xsi:type=). But elements and types are different creatures.

The most important concept to understand here is that the parameter 
elements should be viewed as local elements to the generated RPC wrapper 
element. Therefore they should not be namespace qualified.

Just to make sure you understand this rule, here's an example of what a 
message would look like on the wire:

<e:Envelope xmlns:e="http://schemas.xmlsoap.org/soap/envelope/">
   <e:Body
      xmlns:i="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:d="http://www.w3.org/2001/XMLSchema"
      xmlns:ns1="some-method-uri"
      xmlns:ns2="some-types-uri>
     <ns1:foo>
         <part1 i:type="ns2:type1">First parameter</part1>
         <part2 i:type="ns2:type2">Second parameter</part2>
     </ns1:foo>
     </e:Body>
</e:Envelope>

When using RPC style, the RPC wrapper element <ns1:foo> is generated 
dynamically. The SOAP runtime used the namespace specified in the 
<soap:body> definition to qualify this element. The WSDL <message> 
definition defines two input parts of type ns2:type1 and ns2:type2 
respectively. These types must be defined in the schema, but the <part1> 
and <part2> elements are not defined. Since these elements have no meaning 
except as parameters to the RPC operation, they are treated as local 
elements to the <ns1:foo> element.

I don't understand your question regarding "encoded". The WS-I profile 
doesn't provide instructions on how to use SOAP encoding, but the same 
issues apply to RPC/encoded style. The point is, the specs don't tell us 
how to generate the parameter elements inside the RPC wrapper element. The 
WS-I BP provides guidance -- make them local elements.

Believe it or not XML Schema does permit you to define a schema and not 
specify a target namespace. It's a bad idea, though, and the WS-I Basic 
Profile prohibits this practice.

As far as I am aware, there is no general rule that all elements in an 
instance should be namespace qualified. All *global* elements should be 
namespace qualified, but if an element is only relevant within the context 
of its parent element, then it's quite reasonable to define it as a local 
element.

Note also that the child elements of <soap:fault> are defined as local 
elements, so it would be an error to namespace qualify them in a fault 
message. For example:

<e:Envelope xmlns:e="http://schemas.xmlsoap.org/soap/envelope/">
   <e:Body
      xmlns:i="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:d="http://www.w3.org/2001/XMLSchema"
      xmlns:ns1="some-uri"
      <e:Fault>
         <faultcode>Client</faultcode>
         <faultstring>User Error</faultstring>
         <detail>
            <ns1:reason>Record not found</ns1:reason>
         </detail>
       </e:Fault>
     </e:Body>
</e:Envelope>

If you still don't agree with the decisions made by WS-I, then submit a 
comment to WS-I. Keep in mind that the folks working at WS-I are typically 
the same folks that also work on all the other specs, and the decisions are 
determined through consensus. In any case, WS-I provides a forum to submit 
comments.

Regards,
Anne

At 08:52 PM 2/8/2004, Joshua Boverhof wrote:
>Anne Thomas Manes wrote:
>
>>
>>Josh,
>>
>>The WS-I Basic Profile defines a set of constraints to SOAP 1.1, WSDL 
>>1.1, and UDDI 2.0 that clarifies a number of ambiguities and fixes a 
>>number of errors and contradictions in the original specifications. These 
>>constraints also limit the number of options supplied in the 
>>specifications that make interoperability more challenging.
>>
>>These constraints conform with WSDL 1.1.
>>
>>When using RPC style messages, you don't explicitly define the parameter 
>>elements -- you only define the types. The SOAP runtime system 
>>dynamically generates the element definitions. The SOAP 1.1 and WSDL 1.1 
>>specifications do not specify what namespace these *elements* should 
>>belong to. Hence the WS-I BP clarifies this point. (no namespace)
>>
>>Any child elements of these parameter elements are explicitly defined 
>>within a namespace, thus R2737 stipulates that these elements must be 
>>properly namespace qualified per the schema definition.
>>
>>Anne
>
>This doesn't sound like a good solution to me, I think there are at least 
>four better
>ways of addresing this issue:
>1. make it illegal
>2. use the binding to define the namespace
>3. Use the WSDL targetNamespace
>4. Use the type namespace
>
>Would it be legal to use 'encoded' to specify no namespace for an xml 
>instance, and
>essentially define all of the elements in an instance w/o namespace?
>
>Can I use an XML Schema w/o a targetNamespace in a WSDL document?
>
>The question I'm driving at: Are rpc/literal wrappers the only exception 
>to a general
>rule that all elements in an instance are namespaced?
>
>thanks,
>-josh
>
>

~~~~~~~~~~~~~~~~~~
Anne Thomas Manes
VP & Research Director
Burton Group

Received on Sunday, 8 February 2004 19:10:12 UTC