I think too many .NET developers are simply not returning good stuff from their WebServices. If a .NET WebService returns a DataSet, that can easily be consumed by a .NET application as is. However, *only* a .NET application will *ever* be able to easily consume that WebService. Anyone else trying to consume that WebService will necessarily have to jump thru the XMLDOM parsing hoops in order to utilize what was returned from that WebService. IMHO, all WebServices should return XML, none of this returning DataSets horsesh*t! Especially since it's so easy to do, simply by returning MyDataSet.GetXML(). What's so hard about that? That's my pet peeve for the decade. <g>
~~Bonnie
>>If you take off the ?wsdl and just go to >
http://aspalliance.com/webservices/events.asmx, you'll see a description of the methods you can call. They explicitely state that they return DataSets. You'll need to parse these with the XMLDOM. It would be nice if they had methods that instead of:
>>
>> return MyDataSet;
>>
>>
>>they had methods that did:
>>
>> return MyDataSet.GetXML();
>>
>>
>>But, since they don't, look at what you get back from the WebService:
>>
>> oXML = o.CallTheMethod()
>> oXML.
>>
>>
>>What you'll see (probably, assuming that they are indeed returning a DataSet) is the items that belong to certain objects in the DOM, the IXMLNodeList. Check out:
>>
>>?oXML.item(0).parentNode.xml
>>
>>
>>Anyway, you can mess around with this and parse it yourself, or as I mentioned earlier, wwXML will handle it as well.
>
>Are VFP developers the only ones to use such an advance approach like CursorToXML() and XMLToCursor() instead of having to scroll down each node and do this primitive manipulation? :)
>
>Thanks for the help on this, I'll have to use that approach if I wish to use that data.