>Yea... it appears XML is very flexible. But, for large amounts of data, I wonder how efficient it is then...It is interesting with the SOAP stuff going on now. (http://www.develop.com/soap) It is funny because YAG was doing this stuff at the VFP devcon in San Diego 2 years ago...

Funny you mention SOAP. Just got the new MIND in the mailbox yesterday- guess what's on the cover?

I also wanted to recommend that everybody here take a look at what's going on with BizTalk- www.BizTalk.org. This concept is going to change application interaction completely. In reference to the parallel discussion here on stateless objects, XML is the next logical choice for stateless messaging. There is a practical limit to the number of parameters that you can pass in a single method call before handling your object becomes ugly. (Code Complete states that any routine receiving more than seven parameters should be redesigned). The problem is, with stateless programming, you can't rely on object properties, so there needs to be another way. The answer to this is XML. With XML, you can build a structured request document that contains all of the needed parameters for the method in a single string. You then pass this string as a single parameter to your object, which knows how to parse it and get its operating instructions.

For anybody who hasn't seen it, BizTalk is an application framework that requires that you build a BizTalk compatible Schema for each of your businees messages (the schema standard is not complex, and building a valid BizTalk schema is not difficult). Once you have done this, your application speaks 'BizTalk', and all messaging to and from your application is accomplished with XML documents validated by your custom Schema.

Incorporating BizTalk server in the picture (optional with the framework) allows asynchronous application messaging (using MSMQ) facilitated by content routed messages. IOW, My application A on machine X invokes action on application B on machine Y by building an XML message and throwing it at the BizTalk server, which handles routing. THe name and location of the remote server are built into the message, and read by the BizTalk server, and ultimately by the object itself. This is like the results of DCOM, but without the overhead and complexity of a connection. A standard like BizTalk is an idea whose time has come. This is going to be exciting to watch and take part in.

There is already upheaval over BizTalk in non-MS camps from people who believe (or think they believe) that no one has the right to 'shape' XML messaging this way. They tout that the beauty of XML is that it can be anything, and should not be tamed- but I think that they are missing the point. With standards comes productivity and real-world gains. Without standards, it's all just a jumble.

I have no idea if BizTalk will win this standards war, but I have a feeling it will. Somebody has to, and this framework is much further along than any other I've seen, and MS surely has the muscle to push it. Keep an eye on this one- it's gonna get good.