>>I need to have a specific method, of a Web Service, to return the XML string based on a specific XSD layout which contains the schema definition. Does this mean I can no longer use my method to execute something such as CURSORTOXML(ALIAS(),'lcHtml',1,48,0,'1') and send the contains of lcHtml as my XML string? Would that mean I would have to manipulate each node required in the XSD schema definition file line by line?
>
>Strings results or parameters are never part of the SOAP envelop schema since strings get encoded as XML strings. IOW, they don't travel over the wire raw, but get encoded so it doesn't affect the schema in anyway other than itself.
>
>If you pass binary data (or undefined data) it'll get Base64 encode which also doesn't affect the SOAP envelope, but is more difficult to deal withi on the client side.
>
>The only time objects get embedded directly into the SOAP envelope is when you explicitly define the type in the WSDL which is not directly supported by the SOAP toolkit unless you hack the WSDL after it's been generated which is a hack at best and unmaintainable at worst.
>
>For VFP application passing any 'complex' results and XML around is best to be done as strings.
>
>wwSOAP can handle complex return values OK, but passing it up to the server has the same issues as the SOAP toolkit due to the fact that VFP can't properly export type information in proper case into a WSDL generation easily (back to hacking the WSDL).
>
>IAC, if you're building a Web service string values can be used by all and at this point in the game is probably the most acceptable solution.

Ok, this is all good but is there a way from a VFP Web Service to respond to the need of that client. Basically, the first parameter received is the XSD file and what I will return need to fit within that specific criteria.

My understand so far is that I will have to read that XSD file line by line and define my XML string result line by line as well in order to respect that schema. Or, is there a better way?