I am very happy for us to remove this line of code since I don't think it is achieving very much but I just want to check that I have understood the problem. What is confusing me is that the xsi:type should now never be generated as part of the xml. It should not have been generated in the past, in fact, so all we are doing is using preg to remove something that is never going to be there. 

The reason it is never going to be there is that the wsdl we generate has the request and response structures as elements, not as types, so xsi:type is never needed. xsi:type was being generated in the past, in error by the code that serialised the SDO to XML.

So, although I am very happy to remove the line, I don't see that it can ever cause a problem to have it there. Hence I want to check that I understand...

...so, please would you sketch out a test case that shows the line actually causing a problem?

I would feel more

"I would feel more" is of course a bit of left over text from an uncompleted sentence, and not some vague yearning :-)

Bug 11774 should outline the problem.  When you have an abstract complex type, it is imperative that you show xsi:type.  Otherwise you won't be able to identify what type of element it is.

My point in my last posting was that actually we do not have an abstract complex type in this example. The wsdl that we generate defines the messages and responses as elements, not  complex types e.g.:

<xs:element name="reverseResponse">
  <xs:complexType>
     <xs:sequence>
         <xs:element name="reverseReturn" type="xs:string"/>
     </xs:sequence>
  </xs:complexType>
</xs:element>

... here it is an error to have an xsi:type. If you use XERCES to try to parse xml with an xsi:type like the following you will get an error.

<tns2:reverseResponse 
  xsi:type="tns2:reverseResponse"  <!-- error !!! ->
  xmlns:tns2="http://SoapHandlerTestComponent" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tns2:reverseReturn>MBI</tns2:reverseReturn>
</tns2:reverseResponse>

So my point was that because the wsdl defines elements not types, there should never be an xsi:type for the top-level message or response in the generated xml. The preg that you suggested taking out was there to stop us generating it, a left-over from a time when we were generating when we shouldn't. As I said I am happy to take it out, and will do so, but I don't believe it was doing any harm.

I just looked at this and the underlying Tuscany SDO code is still generating these xsi:types after all. So I believe the preg to remove these is still needed if we are to generate valid xml. 

In fact it does not matter one bit when we are both the generators and comsumers of the xml since the underlying Tuscany code likes the xsi:types. It is because we insist on the element name being BOGUS (because that is how to trigger the right behaviour from the soap extension) I think - the xml won't validate to start with so I don't think we can complain about the Tuscany behaviour.

The preg was removing _all_ xsi:types from the document and not just the first one and yes it was breaking as a result of that.

Ah, of course, thank you, I see now. We don't have a unit test that does that so I had not realised. I have changed the preg so it only removes the xsi:type from the top level element - the message or response - and leaves any other xsi:type's alone. 

That is checked back into FULMAR and will be in the next release.

Suspending this report as the extension have not had a release for almost 9 years.  Please revive this if the extension once again shows life