级别： 初级 郭 路, Technical Manager, ichain Biztech Ltd，Co.
2001 年 1 月 01 日 现在我们已决定在B2B供应链系统中引用XML来表示各种信息流处理对象，不过在引用的程度与方式上我们仍面临着多重选择，本章将从以下五个方面对此进行讨论：
一．我们所需要的 XML文档是Well－Formed还应该是Valid的？
一个Well－Formed的XML文档完全符合XML语法定义，即它的书写格式是完全规范的，而一个有效的XML文档不仅要格式良好，还应该有DTD或Schema来定义其数据结构，一个有效的XML可以用DOM解析器校验其合法性。在一些较小的闭合的网络系统环境中，受开发成本与周期的限制，没有制定物理的DTD/Schema，XML也仅被用于应用模块之间的消息传递，而并不直接作为应用层函数的数据处理对象，应用模块通过解析器从XML文档中提取所需要的文本数据，再转化为编程语言自带的数据类型加以处理。这样做的好处是统一了外部数据的格式，避免在信息交互时受不同编程语言二进制数据格式及结构化数据类型的限制，并有利于系统将来的维护。不过由于没有制定DTD/Schema，应用程序如果要使用DOM/SAX接口对XML文档进行直接编程时会有相当的局限。因为不能引用 NODE_DOCUMENT_TYPE节点类型，在进行一些与 XML文档逻辑相关的信息处理时就必须自己动手编写校验、转化、排序的子函数。不仅增加了程序的复杂度，也会在一定程度影响系统的及时性。另外，最大的问题还在于，系统中XML数据若不指定显式的DTD/Schema，尽管节约了一定的成本，但其代价是牺牲了系统的可维护性、开放性及向后兼容性，如果将来希望对系统升级或和外部系统也用XML交互，就需要对应用重新编译。建议在能力许可的情况下，还是应建立一套合适的DTD/Schema规范，这样才能充分利用编程语言及软件平台对XML的支持，并且通过引用DTD/Schema，可以实现对XML文档逻辑内容完整性与合法性校验的外部封装。
二． DTD/Schema规范应以内部还是外部形式存在？
DTD或Schema的物理定义可以存在于XML文档内部和外部，内部形式的好处在于可以杜绝一些意外的DTD/Schema链接丢失，并且由于DTD/Schema在本地，因此访问速度较快，但一般情况下我们还是推荐采用外部形式，原因主要有三：
- 当某个 DTD被多个XML引用时，如果采用内部格式，即意味着同样的文档要写多次，会造成资源浪费，对于供应链系统中大量的格式化单据信息而言这显然是不科学的；
- 采用外部 DTD/Schema，XML语义与XML数据相互独立，使XML语义规范的单独升级成为可能，只需修改外部的DTD/Schema文件即可，而与XML文档无关；
- 从物理上要求各应用采用相同的 DTD/Schema标准，防止了由于人为因素造成的各应用模块间信息结构在改变后的不同步。
不过在少数特殊环境下，内部DTD/Schema会是唯一选择，如由于底层通信协议或防火墙的关系，而使得客户端应用无法通过URI定位找到外部DTD/Schema。因此，具体在某个应用中XML信息流选择DTD/Schema外部还是内部格式要视环境而定，并非完全一成不变的。
三．采用 DTD还是Schema来建立XML规范？
把时间提前到几个月前，这个问题也许会显得有些多余，因为当时DTD几乎是商业应用唯一的选择，而Schema还只是将来时。
DTD是XML由SGML处继承而来并加以发展的文档类型定义方法，XML是第一次人们试图改变DTD，DTD的功用很多：定义内容模式；限制范围，属性的数据类型，但它也有着天生的缺陷，它本身不是用XML书写的；而且它不支持namespaces(名域)。DTD提供了非常有限的（10种）数据类型，更重要的是它不能表达元素中字符数据的数据类型。
DTD有扩展的机制，但这个机制太复杂而且很脆弱，
DTD扩展的机制的最大毛病在于不能清楚的表达相互之间的关系。两个有着完全相同内容的元素怎么做也不能互相联系。同样的，一组被定义为参数体（parameter
entity）的属性（attribute）之间不能建立任何联系。针对这些问题，以微软为主的IT厂商提出了基于大纲（Schema）的替换方案，Schema是1999年W3C建议通过的的XML-Data描述语言草案的子集，它采用标准XML文档格式的表示法，不仅提供了DTD中标记声明的替代方法，还提供了扩展具有额外功能的DTD的方法：
- XML支持丰富的数据类型（41种），允许对数据更严格的合法性检查，并且可由开发人员创建自定义的数据类型；
- 支持NameSpace名字空间功能，保证标记的唯一性；
- 引入了继承的概念，允许一个模式基于另一个模式，如一个项目合同模式可以基于一个更具普遍意义的电子商务合同模式；
- 由于Schema使用标准XML语法，因此可直接用一般XML解析器对其进行语法分析，并且容易很扩展；
与Schema相比，DTD则拥有广泛的工具支持，所有的SGML和一般XML工具都支持DTD；并具有广泛的应用与经验，DTD应用多年，在实践中人们已积累了许多宝贵的范本和案例。
然而这些优势正在迅速过去，从2000年以来，随着以微软BizTalk为代表的大批Schema标准出炉；各种面向Schema的XML解析、转化工具的诞生；尤其是OASIS、W3C等XML标准化组织宣布对Schema的战略支持，使名为Draft的Schema已成为实际的工业标准，
以目前的技术而言，已足以开发出基于Schema完整的XML商业应用，而更多的商业软件平台在整合XML技术时已开始把Schema放在了首位，尽管在项目开发时我们通常都会更保守些，而且目前基于DTD的应用仍远远大于Schema，不过我个人还是倾向于选择Schema作为XML的文档类型定义方法，XML的发展实在太快了，包括一些技术会被必然的淘汰，而Schema能胜出的原因就在于它更符合潮流。也无须担心Schema会成为微软的又一项垄断技术，唯一需要关注的是，在Schema成为W3C正式标准时，在一些声明的细节上可能还会有小小的变动，也许这正是Schema迟迟未能转正的原因。
四．建立XML规范的原则是够用即可还是要尽量完整？
通常视主体企业的规模、行业的特殊性、项目的目标、开发的成本与周期以及项目背后的支持，我们可以决定在多大程度和哪个层次上完善将要制定的XML规范。显然，制定XML规范的下限是够用，只要设计的DTD/Schema规范集能保证项目中确定部分信息流的有效性即可，不过这仅是满足了系统基本的功能性要求，在此基础上我们还要求DTD/Schema规范集能具有简洁性、合理性、开放性、兼容性，尤其是最后一项，由于不太可能在项目运行前就制定出一个完美的DTD/Schema规范集，以及XML标记本身具有易于扩展的特点，因此，我们应该在设计之初便为系统将来运行中XML规范的升级留出足够空间。并且这种思路是全程的，比如说我们在设计订单信息流的处理时，就应考虑应用层的业务逻辑是否能具备相当的灵活性，当单据的条款数目发生改变时，进行业务处理的函数仍能正确实现其逻辑及结果，而这就要求处理函数在编程时应充分利用文档类型定义实现对XML实体的逻辑判断、校验、定位等。显然，文档类型定义的向后兼容性很大程度上决定了整个系统未来的可扩展性。
当我们为某企业在定制XML规范时，其中不仅会包含商业系统中相通的各种对象，而且也一定会体现出其行业的特点，这二者的有机融合体现了XML规范的完整性。对于技术人员而言，较为困惑的问题就是，如何使XML规范更贴近企业的行业标准并符合其行业的发展方向。通常，在制定与行业相关的XML规范时程序应更为严谨，一般要有该行业领域的专家顾问、国标/企标专家顾问、工商管理专家顾问、国家相关管理部门、企业管理层、系统分析员等共同参与制定，显然当XML规范在更高层次上实现时，其制定的难度也会直线上升，对企业和开发商的实力都是一个挑战。不过对于一些大型的制造型企业，其产品的市场占有率在行业中领先，处于Vertical Market的上游，而且往往与政府的职权部门有着良好的合作关系，因此在制定XML规范时，就可以有更高更广泛的要求，比如说希望在一定的商业领域内通过XML规范实现基于Internet的标准化供销存模式，包括主体企业与客体企业双方的商业操作规则。由于此类企业在行业中的典范作用，因此一般所制定的规范在很大程度上自然具备了一定的标准性，而对于与它合作的那些下游企业，一般对此类规范只有接收，没有太多异议的余地。
对于国内一般的大中型制造企业，如果决定要引入XML，通常较为合理的还是先建立一套轻量级的XML信息流规范，但整个系统应用环境应为其留有足够的扩展空间，这主要是目前国内还缺少制定广泛XML标准的成功案例，也缺少大型的B2B供应链应用管理经验。因此，避免在项目开发期交过多的学费，而选择先让B2B供应链系统运行磨合到一个比较稳定成熟的阶段，并对XML信息化规范的应用有了一定的经验体会，此时再对系统进行阶段性的升级，不失为一个较为保险的良策。
五．使用一个DTD/Schema还是多个DTD/Schema？
事实上，如果在整个B2B供应链系统中全程应用XML的话，只定义一个DTD/Schema几乎是不可能的，那样的一个DTD/Schema会非常“胖”，而且有许多XML信息流在不同应用环境下其定义与用途是不同的，比如一份招标书在客体企业而言就是投标书，当投标成功后就成为一份完整的项目合同；一份采购预通知在审核后就成为采购通知单，当供应商确认后就成为一份订单，而当物料生产完送到主体企业工厂仓库时就成为一份送货单，当物料验收入库后又可以成为一份帐单……因此，我们的下一个问题就是，要怎么对DTD/Schema进行归纳划分。
由于XML文档总是面向实体的，因此我们可以理出在一个制造型企业中会有哪些基本的实体，如单据实体、金款实体、文档实体、物料实体、产品实体、公物实体、项目实体、消息实体、客户实体、人力实体等等，通过DTD/Schema我们可以确实地给出每个基本实体的定义。然后由顶至下，我们希望可以系统地得出实体的划分细化方式，通常有三种不同的基本原则：按职能划分、按流程划分、按资源划分。
传统的商业管理系统中，通常是按职能建立对象模型的，比较典型的就是MIS系统。然而近年来，这种对象划分方法已经逐渐落伍，因为它基本上只是表面地重现企业的物理组成，无法体现企业在更高层次上的抽象，当然也无法为企业带来真正管理上的优化。按流程分的基本思路是以计算机算术模型的方式重现企业生产运作的流程，通过抽象与统计，找出企业运作中的瓶颈，然后以调整或重组的方式来优化流程，最终达到提高企业效率的功能，其典型的案例就是MRP。流程管理能较合理地利用计算机建立企业的高级抽象模型，为企业决策与管理提供参考信息，不过仍有其不足之处，现代大型企业的信息化管理不仅是要求高效率，快节奏，更强调各管理模块的无缝集成，信息的综合管理及交互，而流程管理往往局限于一定的生产模式，无法对复合型的管理环境提供很好的支持，于是就有了更高级的对象划分方法，即按资源划分。在这种对象模型中，将企业的有形资产（资金、货物、人员等）与企业的无形资产（如客户、信息、企业文化等）通通定义为企业资源进行统一的集成管理，以期实现对企业资源的最高利用，而基于此的商业管理系统就是通常所说的ERP系统。其基本的商业管理对象包括：订单、采购、库存、生产计划、质量管理、分销、服务与维护、财务、人力资源、项目、配方、投资、客户、市场与营销等等——这也是我们对XML实体对象系统细化的重要依据。
通常对于B2B供应链的前台与后台系统，我们会使用两套独立的XML规范，尤其当前台B2B网站构建在某个ASP的平台上时，这种选择几乎是必然的。前/后子系统间XML信息流的交互需要通过XSLT词汇表的转化，为节约开发成本，两套XML规范在局部可以是相同的，但并不强调可参照性。由于前台系统直接与客体企业的系统握手，因此其XML规范的制定更强调国际性、流行性、广泛性、友好性、开放性，通常会以某个XML电子商务国标为蓝本，并作少量的改动。后台企业的ERP/MRPⅡ管理系统则是内部闭合的，因此其XML规范的制定更强调专业性、简明性、功能性，一致性，相对前台B2B网站，后台系统XML规范对通用性的要求却较为松散，也就是说可以使用“方言”。比如我们对后台系统的XML信息流可以采用中文的XML标记及GB2312编码，而且可以根据具体应用的需求定制标记，但对于一个专业的B2B网站，通常就必须采用英文标记及Unicode编码。与前台系统相比，后台系统中XML标记的属性、类型等约束更细更严格，因为标记的逻辑涵义与限定通常是与详细设计的流程相关的，如某企业其规定其常规件的采购提前期最大为20天，定于每月初采购一次，而其最小采购量为100单位，则常规件的采购订单Schema可以声明如下：
<?xml version=’1.0’ ?>
<schema xmlns=”urn:schema-microsoft-com:xml-data”
xmlns:dt=”urn:schema-microsoft-com:datatype”>
<ElementType id=”常规件采购订单>
………… ……
………… ……
<element type=”有效期” occurs=”REQUIRED”>
<min>1</min><max>20</max>
</element>
<element type＝”采购量” occurs=”REQUIRED”>
<min>100</min>
</element>
………… ……
………… ……
</ElementType>
</schema>
|
如上所述，企业后台管理系统的XML标记定义是与系统流程密切相关的，因此很难跟随或照搬某个XML的行业标准，不过它仍然是我们制定规范时重要的参考依据。目前国内还缺少可供参考的XML行业标准，在实际设计规范时除了参考一些国外XML行业标准外，还可以参考国内外相关的EDI单证、行业标准和SGML的行业DTD，其中有更多关于商业规则的约定。另外，我国的传统制造业多为社会主义制度下的国有企业，因此企业的XML规范也必然会带有鲜明的中国特色，比如在部门实体中就可以包括工会和党/团支部等子元素。
目前，国际上关于电子商务类较为成熟的XML标准有Ariba推出的cXML，CommerceNet的CBL等，在此之上还有更完整的XML电子商务架构方案如SUN、OASIS、UN/CEFACT力推的ebXML，CommerceNet的eCo，微软的Biztalk，而我国在这方面还是刚刚起步，目前以中科院电子商务研究中心为核心的www.cnxml.org.cn已开始着手制定符合中国国情的XML标准，各大公司/企业也可将其制定的XML规范发布到此站点上，相信在不久的将来，我们就能看到由国人自行设计的XML B2B商业规范。
名词解释：
UN/CEFACT：联合国贸易促进与电子商务中心
(United Nations Center for Trade Failitation & Electronic Commerce)
SAX：XML简单编程接口（Simple API for XML）
CBL：通用商务库（Common Business Library）
DTD：文件类型定义(Document Type Definition)
ebXML：电子商务XML（Electronic Business XML）
XSLT：可扩展样式表转型语言(extensible stylesheet language transformations)
DOM：文档对象模式（Document Object Model）
EDI：电子数据交换(Electronic Data Interchange)
URI：统一资源源识别器(Universal Resource Identifier)
参考资料
关于作者  | 
| | 郭路，杭州大学计算机系92届本科应用专业，曾先后就职于浙江省纺织经贸总公司计算机中心、思能软件、华企、飞时达等软件公司，担任技术主管，主要从事于企业
MIS、GIS、ERP 及电子商务项目的开发管理和系统分析，对 IBM、微软、SUN、Autodesk 等公司的企业级产品有较深的研究及理解。 |
对本文的评价
| 
