>>>It depends. It could be a string containing a single value or a large XML document. It could be an array. It could be a recordset. It really depends on how you want to transmit messages between tiers. My personal preference for most situations is XML because it is so easy to parse with the new tools that are available. But it would be foolish to generate an XML document when all you need is a single value or an indication that an operation passed or failed.
>>>
>>>Use a method appropriate for the message being sent.
>
>Adding to Bob good explanation, you also have to keep in mind performance/flexibility issues.
>
>XML is (until now) a bit slow to parse when the result set is big. Of course, one of the goals you have to keep present is that in an n-tier app you have to avoid this, but there are always circumstances in which data sets are inevitably longer.
>
>ADO is faster for that.
>
>Anyway, ADO is great when you are inside the same network, and XML is better suited when your tiers connect accross the internet (for example in a Web Service). XML is text, and it had excellent compression over HTTP, and it passes freely across firewalls.
>
>And as Bob said, many times it's enough to return a simple return value.
>
>As always: the right tool for the right job.
>
>Hope this helps,

Yeah, I can see the benefits.

Following on from your example, one thing I've just been looking at is validation of entered values.

My first reaction was that the middle-tier should check validity of passed values, because the UI doesn't need to know what data can be accepted.

So if say, entering a product code, you accidently put a space in the middle, should the middle-tier be the tier to pick that up and return an error code?

Thanks
Kev