1.按你这种方案设计来做应用的话，是不是简单些的查询、增删改基本上不用什么ASP程序了？

目前我们还是写了不少ASP，不过这些ASP都很小，目标是少些ASP，至少是尽量自动生成ASP程序。
再加上系统的URL自动处理功能的话，大部分功能是可以不需要ASP程序了，不过总会有些复杂的功能
尤其是在管理系统中，还是需要ASP的，不过应该也大都是通过整合自动生成的ASP来完成。


2.再就是这种方案做展现是直接的BS要求界面开发人员在知道底层库结构和业务逻辑，而不是B+M(中间件）＋S 了？

我觉得这种方案还是标准的B+M+S的方案，只不过这里面的M是个通用的M，什么系统都就是这一个，
界面开发人员不需要知道底层库结构，他根本就看不到库结构，也不知道库结构的存在，业务逻辑
总是需要知道的，不过业务逻辑都是XML的形式，比如
(1)要增加帖子：
<command name="增加帖子">
<msg title="{标题}" content="{内容}" type="图标类型"/>
</command>
(2)删除帖子：
<command name="删除帖子"><msg id="{帖子ID}"/></command>
页面开发人员根本不管数据库结构和数据库类型以及数据库位置。

3.另一个疑问：
这个通用的COM组件＋XML是为了更方便的持久化数据还是因为做为XML形式的结果方便在客户端做展现？
现在看来对两者都有改进，那设计初衷更偏向于哪方面呢？

说起来惭愧，我对“持久化”的意义总不那么领会。展现无疑是比较方便了，页面不再需要到处包含
服务端脚本代码，修改网页不会再那么烦了，没有真实数据时，可以弄一套静态的xml文件测试。

HTML+JS+CSS+HTC等等，虽然很多，但HTML+CSS本来就应该是一个网页开发人员的基本要求
JS+HTC吗，我可以先做好，大家用就行了，呵呵，现在我们的系统就是这样，HTC也是我做的
大家反映好的很，很多功能不再需要象以前那么烦了，因为甚至分页功能我都封装进HTC了。

其实设计这种结构的初衷很简单：我需要抽身出来单独攻工作流，又没有其他人会VC,Delphi之类的，
COM+也都不熟悉，我不能因为其他那么多功能的要求，写那么多组件和方法，天天和他们一起测试，
正好因为研究工作流把XML,XSL,Schema,XPath等弄明白了，所以就弄了这么一套结构，
现在我只做工作流，其他的功能我都不用管。
另外的好处时，由于组件基本上定型不用再改，以后修改业务功能，增加业务功能不在需要编译中间件
可以做一套页面，修改修改服务端的Schema文本文件就可以，远程维护简单了。