在传统的大型项目中，一个业务建模后，在实施阶段数据定义会重复的分解到下面几个地方：
1. 数据库
2. 数据层的Entity或者DTO
3. Service层的传输对象
4. 表现层的数据
5. 用户录入
6. 报表等其它应用。。。
上面每个层次都要定义自己的数据格式，验证方法，这是多么重复而又没有意义的劳动。
而且受到每个环节定义能力的影响，数据的验证和意义不一定能体现出原有的需求。
那么，谁是终结者呢？schema!
schema是dtd的晚辈，但是更强大，灵活。我们知道，一般说来schema仅仅用于定义xml并且验证xml。
但是schema也提供了扩展空间，就是annotation. 在annotation下面，可以定义
document，document是对schema的注解。另外一个挂在annotation下面的是appInfo，从名字看，
这是给应用程序提供信息的空间。从schema定义看appInfo可以不受限制的存放各种xml数据。
这是我的一个例子：
<xs:complexType name="customer">
<xs:annotation>
<xs:appinfo source="meta">
<meta:appInfo xmlns:meta="http://steeven.org/meta">
<meta:title>客户</meta:title>
<meta:tip>下订单的客户</meta:tip>
<meta:help>产生交易的下单客户</meta:help>
</meta:appInfo>
</xs:appinfo>
</xs:annotation>
.....
..... //这里是type的定义
</xs:complexType>
可以看到，在定义一个customer的时候，我们可以为其加上meta信息，告诉程序，这个数据的名称，tip，帮助。
如果需要，甚至可以定义帮助链接，辅助输入的数据来源，辅助选择的控件名称。
这些meta元信息，无疑为调试，接口，UI，报表等场景提供了宝贵的信息，使画面自动生成成为可能。
那么一个全局的schema定义有什么好处呢？
1. 从上面的几个场景看，利用schema生成上面几个场景所需的代码易如反掌。这些代码带有自描述，验证。重要的是，层间传输的不再是毫无意义的数字和文本，它们是活的。
2. schema支持schema之间的引用，type的重定义或者扩展。重用或重组已有定义将十分容易，并且annotation可以被继承。
3. schema是语言无关的，意味着什么呢？schema定义可以用不同语言实现。
4. 配上规则引擎是业务层，配上基于schema的画面生成就是用户界面。配上xml数据库，存储问题也解决。
两年前，我曾经做过一次半成功的尝试。我先定义了全局业务数据schema, 然后生成了数据库schema，
当然数据库schema引用了业务schema, 因为业务schema是源头。
接下来，因为是个b/s项目，我又定义了画面的request schema和response schema。
有了这些schema剩下的任务就很简单：根据数据库schema, 生成了sql建库脚本。
根据request schema和response schema，前台人员制作了xsl，用于转换xml成网页。
response schema用于校验业务层的xml输出。并且这两个schema都生成了样本数据，用于前台人员后后台人员独立调试。
由于schema引用, 设计做的快速，语意准确，甚至很多描述直接写进了schema的annotatiion。
但是也有不尽人意的地方，比如当时我们自己定义了schema到Bean的转换规则，并且手写了bean代码。
并且开发人员学习xslt和理解schema也花了点时间。
现在的开发人员很幸福，各种基于schema的工具有很多选择。
从长远看，直接存储xml，利用规则引擎，基于schema动态用户画面将是发展方向。代码几乎可以销声匿迹。
总结一下：
1.基于schema的全局数据定义即保证了数据定义在全局的一致。
2.提供了代码生成的基准，生成式的代码大大减少了开发和变更的成本。
3.基于schema的动态生成是最高理想。
参考资料：
schema spec
xmlbeans
.net schema文档
jaxme
@TODO:
动态echo/swing/swt画面生成。
schema appInfo写作工具。
其它代码转换工具
