+1  A: 

We had a similar problem with Delphi 2009 and a standard Soap service (CRM). It was not related to attributeGroup. We found so many incompatibilities that we finally decided to use a small C# application as a proxy for the real .Net based service.

mjustin
That's exactly what I'm afraid of. How did you connect the C# proxy app to Delphi?
cjrh
It was a unidirectional interface - we used simple XML files to move data from the inhouse system to the CRM. We could also have uses a simple Soap server in the C# app which can be consumed by the Delphi app, or a HTTP server with JSON. But for inhouse interfaces, simple file based exchange is ok
mjustin
+1  A: 

Hi,

I was the poster of the first reference you give. I think I found out that this bug has never been fixed.

I later posted another question on the Embarcadero Developer Network where Nick Hodges said that

We are concentrating on client development [...] if you are looking to build SOAP servers, then I'd suggest that you also give Delphi Prism a look.

We decided to switch to C# for development of our SOAP servers. I decided to let the service talk to a database, which is then accessed by our Delphi application.

Later I ran into problems with client development under Delphi as well, so we're doing that in C#, too. This time the C# class is com visible and can be accessed from Delphi. Seems to work fine.

Regards, Miel.

Miel
Many thanks for your reply! It seems I may have to go the C# route here. I like mjustin's use of file-dumping for data exchange (because it is so simple), so I'll probably go with that, because you get logging basically for free. Thanks again.
cjrh
+1  A: 

Ok, this one took a while.

According to this post, there are certain tags that the .NET wsdl.exe tool just won't recognize when importing a wsdl file. According to MSDN:

attributeGroup: Ignored. DataContractSerializer does not support use of xs:group, xs:attributeGroup, and xs:attribute. These declarations are ignored as children of xs:schema, but cannot be referenced from within complexType or other supported constructs.

This behaviour is also described (albeit in a very hard-to-understand manner) on one of the MSDN blogs. In my specific case, the particular part of the wsdl file causing the problem looks like this:

 <xs:complexType name="PhonesType">
     <xs:annotation>
         <xs:documentation xml:lang="en">Provides detailed phone information.</   xs:documentation>
     </xs:annotation>
     <xs:sequence>
         <xs:element maxOccurs="unbounded" name="Phone">
             <xs:annotation>
                 <xs:documentation xml:lang="en">Used to pass detailed phone information.</xs:documentation>
             </xs:annotation>
             <xs:complexType>
                 <xs:attributeGroup ref="TelephoneInfoGroup"/>
                 <xs:attributeGroup ref="ID_OptionalGroup">
                     <xs:annotation>
                         <xs:documentation xml:lang="en">The ID attribute in this group is a unique identifying value assigned by the creating system and may be used to reference a primary-key value within a database or in a particular implementation.</xs:documentation>
                     </xs:annotation>
                 </xs:attributeGroup>
             </xs:complexType>
         </xs:element>
     </xs:sequence>
 </xs:complexType>

It seems that the <xs:attributeGroup ref="TelephoneInfoGroup"/> is being ignored by the .NET wsdl.exe tool, just like it was being ignored by the Delphi wsdl importer. In such a situation, where importing fails in both Delphi and .NET, the wsdl file probably has to be changed, and that means I will have to use my home-made python ref-flattener after all.

cjrh