When you say Stored Procedure input and output values will be XML you mean the application will only support SQL Server? How are you planning to handle the XML?
The long term goals of the CSK 2.0 is to make it non-dependant on any one database platform. However, for the first cut it will be built against SQL 2000.
The next major piece of information is we are building data providers. These break down to User/Security, Site, WebApp (one app can have many sites!) and Content.
With all of this in mind, the Content_Sql provider(s) will be using XML to talk to SQL server. When we go to add new providers it will depend on if they handle XML. If not, the XML will need to be broken back to typical ADO.NET structures to talk with that data store. Each case will be handled individually.
What this gives the developer of any CSK module is the liberty to develop and only have to learn a single provider interface and the data providers handle everything from there.
Are you planning on use the Provider Design Pattern to abstract an API for the data providers?
Could you explain why the design decision was made on using XML as input/output? As for input parameters, would it be only one? or many of the varchar type?
I was used to use XML as output with SQL 2000 back on the old days of ASP 3.0. But I haven't use this approach on any of my .NET applications yet.
I'm hoping to address this in another article real soon. The skinny of it is this:
Using XML I won't have to change my data providers if I decide to add/delete/change a column or two. The data providers will consume and produce XML on the UI side and will talk with the data stores via SQL if it can or in the data store native language at worst.
Hope that makes sense.
(Once I have my .Text site up and running I plan to add diagrams to the articles so it can be pictured easier.)