And now to substantiate the most obscure title ever...
Say you have an ADODB XML packet, i.e. ASP's "short" default version of the XML recordset for a query executed through the ADODB/ADO facility. In sum, this XML is horribly inefficient because of the recordset's schema in present in EVERY SINGLE ADO XML packet. This XML format is similar to a proprietary SOAP XML packet - which again is a horribly bloated format.
Say we have a 3rd party API that utilizes the ADO recordset as it's return string. And we're using a programming language to capture said record set that is not ASP or a language that can natively utilize the ADODB facility - even if it's through COM Services. ADODB is usable through COM Services - but testing with several languages instantiating an ADO COM Object and seeing how much trouble is with conversion of even simple data types - this method is not eligible even in the development environment.
Since there is a bit of overhead involved with the utilization of a ADO object in any language that doesn't natively support the ADO facility - I use XSLT to transform the "simple" ADO XML into a WDDX packet.
I must disclaim that I've tested this XSLT with ColdFusion and the "simple" ADO XML recordset for simple MSSQL select query results. For instance it XSLT translates the "r:data" section of the ADO XML into a simple "hash" aka "associative array" aka "struct".
Here's the first proof-of-concept .XSL file I created - which works rather well: