As I promised in my last post, here's a guide to the WSDXML_* structures used in DOM processing in WSDAPI. Before I get started, a quick statement on DOM: Document Object Model is a way of representing XML nodes as static structures in memory. The structure looks like a tree, and contains elements, attributes, and text. WSDAPI uses these DOM sections to represent any data it doesn't understand in a message; these sections are captured in the xs:any declarations in XML schema.
OK, on to the structures:
The WSDAPI XML parser will build trees of these structures to represent XML received in a message. If you want to build your own trees of arbitrary data to pass down into WSDAPI, use the following functions:
Although it's possible declare WSDXML_ELEMENT structures statically, I find that it's usually much easier to build them at runtime with WSDXMLBuildAnyForSingleElement.
These structures and functions aren't particularly complicated, but here are some hints to successfully create and consume WSDAPI DOM sections:
Now that you know how to parse and generate these trees, you need to know how to get access to them in generated SOAP messages. Not all fields in a SOAP message are extensible; xs:any has to be explicitly defined in a type, and WsdCodeGen will turn that declaration into a WSDXML_ELEMENT field in a structure or parameter list. In cases where xs:any is defined in an application-specific type (e.g., a type in WSD-Scan) these parameters will appear in generated code; in cases where they appear in native WSDAPI messages (WS-Discovery or WS-Eventing messages), you need to use advanced versions of WSDAPI methods or configure your generated code to expose them.
And that's about it. So, now you know how these structures work, how to generate and consume them, and where you can access them in WSDAPI.