XML 编程思想:利用模式标准化实现自上而下的语义透明

【 tulaoshi.com - Web开发 】

　　本期文章将继续探讨语义透明的许多不同方法，介绍这些方法对使用 XML 的开发人员的影响。长途旅行中节省体力的一种办法是搭便车。在 XML 中，可以利用数不清的开放的模式计划，其结果就是通过模式标准化实现自从而下的语义透明。但这并非完全免费的搭便车。在本文中，Uche Ogbuji 考察了第三方模式重用的优缺点。他还提到了 The Semantic Technology Conference 2005，对最近关于姓名建模困难性的讨论作了答复。

　　从上一期文章Thinking XML: XML 建模艺术描述开始，我计划就这一话题写三篇文章，恰好完成本专栏的第 30 期。上一期文章概述了语义透明的一些有趣的技术和方法，包括我对最新进展的一些看法。本文是第二篇，将查看采用具有定义明确的语义的现有 XML 格式的优缺点。不过首先要提一下我在三月初参加的一个有趣的会议。

　　The Semantic Technology Conference 2005

（本文来源于图老师网站，更多请访问http://www.tulaoshi.com/webkaifa/）

　　在得克萨斯州奥斯汀召开的 Knowledge Technologies 2001，是我参加的第一个强调与 XML 相关的语义技术的会议。在那次会议上，我看到这类技术潜力的活力和激情。但出席这次会议的主要是一些研究人员和前沿的商业机构。商业代表很少，这在很大程度上反映了技术采用周期的变化。XML 早期的采用者仍然必须让商业投资机构相信语义技术的价值，而在这样做的时候，这些采用者发现，因为语义技术很可能延续 XML 的成功，所以他们很大程度上（并且很奇怪地）面临着与 Web 服务的竞争。

　　我曾经在本专栏中提到，最近商业机构开始看到了语义技术的重要性，3 月 7-10 日在旧金山召开的 The Semantic Technology Conference 2005 也反映出了这一点。与四年前相同的那些人员和主题又重新出现了，但这一次, 与会者大大增加了，主要是商业投资者增加了。从风险投资者（通常是进入周期中某个阶段的信号）、技术经理到企业家，人们不但讨论语义技术的潜力，还讨论商业机会和预期的投资回报。我对 2001 年会议的活力留下了深刻的印象，但这一次却是令我震撼。而且这也是我参加过的组织最好的一次会议。

　　我作了题为XML Design for Semantic Transparency（参考资料）的发言，阐述了我在本专栏以及其他 developerWorks 文章中讨论过的主题。我一直没有把目光放在语义 Web 的远景上，而是关注语义技术的现实应用，以提升 XML 技术的价值。听众对我的发言予以热烈的响应，令我深感荣幸。我仍然认为业界还没有充分利用 XML 和语义技术结合的强大威力，您也可以投入到这一不断加强的趋势中来。建议您对 Semantic Technology Conference 2006 保持关注，我将参加这次会议。

（本文来源于图老师网站，更多请访问http://www.tulaoshi.com/webkaifa/）

　　搭上语义高速公路的便车

　　XML 出现之后不久，业内组织就开始雄心勃勃地为各种各样的信息研究基于 XML 的标准。这种强行解决语义透明性问题的方法就是我所说的自上而下的方法。这些小组希望定义整个文档的格式，以及所有元素、属性和内容的语义。这种方法常常要依靠已有的行业数据词典或者其他这类标准，如果有的话。有时候就以 EDI 标准作为起点。

　　重用这类标准可以减少开发语义透明数据格式的工作量。这样做的好处包括：

便于和采用相同格式标准的业务伙伴集成。 定义明确的语义，不仅仅是单个数据元素，还包括它们的关系和预期的处理模型。 可能减少培训和招募新人的高昂费用，如果使用众所周知的格式，那么劳动力市场中会有更多人熟悉它。 减少出现规则问题的机会；如果从事规则控制的行业，可能会发现有关规章要求或强烈建议在内外部信息交换中使用特定的数据格式。

　　当然，也要考虑到以下不利之处：

标准化的数据格式不一定非常适合您的特殊要求。标准是利益竞争的妥协。标准常常由委员会制定，每种文化中都有关于通常由委员会设计的粗陋成果的尖刻讽刺。您可能会发现，要适应主流标准框架需要做很多工作。很多标准将可扩展性作为一种逃避的理由，如果不小心，您就会陷入极力避免的语义透明性问题。 可能会遇到知识产权障碍。与任何热门技术一样，XML 空间中堆积了大量可敬而琐细的版权和专利权，这些对知名的数据格式和某些处理惯例产生了影响。要考虑法律上的障碍和解决这些障碍所花费的代价。 关于竞争性标准的讽刺非常适合于 XML。基本上，在商业利益的每个领域，都有多种竞争性的 XML 标准，您会发现自己处于采用哪一种标准的选择游戏中。此外，由于没有足够多的标准注重应用支持联合使用竞争标准的语义透明技术，您可能发现自己被锁定到最初的选择上。

　　词汇表的部分采用

　　您可以选择折衷的办法，采用标准化的词汇表，同时扩展或者修改它，以满足自己的需求。如果这样做，那么一定要多注意完全自行创建词汇表时所作的保持语义透明性方面的努力。参考目标格式文档或者数据词典中的资料可以省不少力，但是如果有什么变化的话，则需要更加注意形式化所作修改和扩展的语义。确保与使用相同标准的其他词汇表相比，不会对互操作性造成损害。

　　对于这类折衷，还可以考虑不那么常见的一种方法：从选定的语法处理单独语义的模式系统。借助外部的格式或许就能满足您的需要（虽然通常需要专门化语义而不是语法），下一篇文章中将讨论实现这种方法的工具，如 Schematron 抽象模式和 XML 体系结构表单。

　　姓名的命名

　　现在开始讨论本文的第二个主要问题。John Cowan 是 XML 领域最博学的专家之一，最近参与了关于 OpenDocument 文件格式（以前称为 OpenOffice XML 格式）的讨论论坛，本专栏以前的文章中曾经介绍过这种文件格式（请参阅参考资料）。我曾在 developerWorks 中多次提到建模姓名是一个非常困难的问题，John 的建议很好地说明了这个问题有多么困难。他写道：

IMHO（我曾经研究这个问题多年），结构化姓名使其适应不同文化（随着学术研究的国际化，这个问题反复出现）的所有尝试都失败了。西欧及其文化后裔将姓放在最后显示，但是称呼的时候放在前面。 匈牙利人总是将姓放在前面，至少在匈牙利语中如此。 中国人也将姓放在前面，而且在其他语言中提到时也常常保留这种习惯。 冰岛人（多数）没有姓，只有名和父名，称呼和显示都是使用名+父名的形式。 印度尼西亚人多数只有一个名。 我认为统一的惟一办法就是用两种方法表示全名：一个用于显示，一个用于称呼。可以使用下面的标记法：namepart key='2'John/part part key='1'Cowan/part/name 但我认为真的没有这个必要。 name sortAs='Cowan, John'John Cowan/name 虽然内容有重复，可能更合适。

　　从建模的观点来看，这是一种合理的办法，但确实造成了这种难堪的可能性，即必须输入个人的姓名两次，从而确保名字不同形式的正确性。事实上，后来在讨论中，Cowan 曾提到过如果在这种情况下抄捷径会有多危险：

将姓名缩写成[最终表示的]格式需要手工调整，比如中间名O'Flynn缩写为O'F.，或者知道Willard van Orman Quine是Quine, W.V.O.的完整形式。即使自动倒转姓名也很难：William Lyon Mackenzie King倒转后成为Mackenzie King, William Lyon，虽然我们通常称呼他King。

　　同一个论坛中，David Wheeler 提供了一个建议，很好地说明了跨文化建模姓名的重要性：

有一些命名标准，但是真正国际化的标准过于复杂，实际上从未使用过。

　　John 在发给我的一条消息中提到，他曾经遇到这样的命名问题：在[国际电子邮件地址和传输标准] X.400 和[国际目录标准] X.500 上下文中，前者提供了完整的头衔、名、中间名、姓和‘一般称谓’（即 ‘Sr.’、‘Jr.’或‘III’），后者出现的较晚，只有‘常用名’和‘姓’。前者非常适合显示，称呼实际上使用的是后者。

　　建模姓名是一个老问题，这个问题并没有随着技术的逐渐全球化而变得简单一点。虽然只有少数人会直接面对国际化姓名建模的复杂性问题，但您脑子里应该对这一问题的困难有所了解，对这种最常见而令人尴尬的建模问题做好心理准备。

　　到底什么是标准？

　　我一直建议至少要考虑使用外部开发的 XML 词汇表。自己设计 XML 格式似乎很简单。但我从实践中了解到，设计一种有用的 XML 格式能多么难呢？通常是在以后陷入困境的前奏。在寻求语义透明性的过程中，决定是否采用行业标准的重要一步是发现和评估候选标准本身。XML 的流行造成了 XML 标准格式开发的泛滥，因此这个问题也不一定很简单。在最近的技巧文章（请参阅参考资料）中，我介绍了一些寻找适当的 XML 词汇表的地方。本专栏中也重点讨论了特定行业专用的一些标准，以及一些更通用的标准。请加入 Thinking XML 讨论论坛，分享您使用流行 XML 格式的经验。