> In .Net or ASP.net, dataset is XML. Database manipulation in .Net is
> based on XML. XML instead of object has many benefits. Portability over
> network and platform, persistence over file or memory. So you serialize
> object or recordset into XML.
>

No, the dataset is not XML, the dataset is an object. It has means for
serializing itself into XML, but if your scenario doesn't require it, why on
earth would you do it? TS's scenario is an ASP.NET webfront with a SQL
Server backend. Even if he has a middle tier that does the data-access and
passed the serialized (read XML) ADO datasets, on the ASP.NET pages, they
would still treat the object as a dataset. In fact, it would be really dumb
to not do that since you can attach WebForms controls to the dataset.

Even if XML is used underneath, the ASP.NET programmer doesn't need to know
nor care about it.

> In legacy ASP also, you can retrieve data as XML from SQL(such as 'for
> xml'), and transform the XML with XSLT. This scenario has some benefits
> over old recordset+loop. First of all, you can save valuable resource
> of connection by disconnecting early. Next, you can separate
> presentation logic using XSLT.
>

Not at all. In fact, that sounds like a LOT more overhead than necessary. In
classic ASP, you would execute an ADO command in a disconnected fashion.
This retrieves all the data, the connection is immediately disconnected.
After that, you now have an object version of your data, and you can do what
you need to do with it. If your site is hit very hard, you would probably
have a COM middle tier that did the dataaccess for you and passed streamed
ADO messages (i.e. the ADO XML) that would then on the webpage be loaded
into an ADO object, etc.

The point is here that XML is not at all needed for either scenarios, and in
fact adds more overhead than is needed.

-BKN