XML 编程思想: Harold 的高效 XML 设计原则

2016-02-19 16:50 1 1 收藏

关注图老师设计创意栏目可以让大家能更好的了解电脑,知道有关于电脑的更多有趣教程,今天给大家分享XML 编程思想: Harold 的高效 XML 设计原则教程,希望对大家能有一点小小的帮助。

【 tulaoshi.com - Web开发 】

  知名 XML 专家 Elliotte Rusty Harold 的著作 Effective XML为 XML 技术用户提供了最佳实践。该书中关于 XML 设计问题的多数讨论 Uche Ogbuji 也曾经关注过,在本文中,他以该书为线索,进一步探讨了 XML 设计和最佳实践。请在本文的 讨论论坛上与作者和其他读者分享您对本文的看法。

  我的同事 Elliotte Rusty Harold 是一位知名的 XML 教育家和 XML 软件开发人员,他以其他方式为 XML 的发展作出了贡献。我们都对 XML 用户和开发人员的最简实践和清晰思路抱有浓厚的兴趣。在最近的 developerWorks文章中,我提供了自己关于这方面的建议和经验。Harold 则把他自己关于这方面的思考整理成了一本书 Effective XML。正如该书的主页上所指出的那样:

Effective XML是关于使用 XML 的指导原则和最佳实践的汇总。它关注的是如何使用和开发 XML 应用程序,并特别强调了 XML 的哪些方面经常被误解和滥用。

  本文将讨论 Harold 的著作,并融入了我自己对 XML 最佳实践和规则的变化的研究。

  预示着成功的开始

  甚至在进入该书的第一章之前,就出现了无论如何都不应该忽略的资料。引言中有一节对经常混淆的一些 XML 术语进行了分类。准确地理解和谈论 XML 中很多微妙的术语是正确使用这项技术的基础。Harold 所做的辨析并非学究式的吹毛求疵,他真正理解了 XML 背后核心概念的关键。我从Namespace versus Namespace Name versus Namespace URI一节学到了重要的一课。我经常随意地使用这三个术语,非常感激该书中所作的提醒。

  第一部分介绍了 XML 语法,文章讨论的第一个话题(和书中的其他多数概念一样)与我在自己的文章中讨论的一些话题非常类似,具体到本例,该话题就是我写的技巧文章 坚持使用 XML 声明。我非常不同意书中接下来的一章Mark Up with ASCII if Possible中的观点。我一直认为, XML 完全以 Unicode 为基础是驳斥 ASCII(和单纯使用英语)偏见的一个好理由,这种偏见仍将牢牢控制着软件行业。我认为 XML 正在迫使盲目崇拜纯 ASCII 工具的开发人员提供更好的国际化工具。与其为了适应少数没有赶上时代的工具而重新考虑 ASCII,还不如让用户强迫其供应商实现国际化(也许只需通过选择不同的厂商,求助于市场的推动即可)。Harold 的建议主要针对的是标记(如标签名)而不是字符数据,他还认为必须将字符数据本地化。在后面的一节,Write in Unicode中,他也朝正确的方向迈出了一步,但是我认为他在这方面的建议对英语报有很大的偏见。

  Harold 是开发 XML 1.1 的主要反对者之一,他的意见在 XML 社区引起了神秘而有趣的讨论。Stay with XML 1.0这一节清楚地说明了他对足够清晰的术语这一问题的看法,我建议所有必须考虑是否支持 XML 1.1 的人读一下这一节,特别要注意 XML 1.1 的支持者提出的那些相反观点。对于我而言,我准备只要可能就继续坚持使用 XML 1.0,但有趣的是,我也注意到,有一个问题也许会迫使我转向 XML 1.1:对于可用于 XML 标记结构的字符,它放宽了很多不必要的限制。因为 Harold 更愿意坚持在标记中使用 ASCII,这样的话不理睬 XML 1.1 当然更容易,不过我已经表明不赞同避免使用非 ASCII 标记。

(本文来源于图老师网站,更多请访问https://www.tulaoshi.com/webkaifa/)

  我发现很多和 XML 有关的 1.0 技术在技术上都很卓越,通常因为它们是由才华横溢的个人或者小组来推动的。不幸的是,1.0 规范的成功带来无数形形色色对 1.1 或者 2.0 版开发过程的关注,结果, XML 技术开发成了由政治操控并由委员会设计的一个大杂烩。我对 XML 开发人员也有类似的建议,即 坚持使用 XPath 1.0 和 XSLT 1.0 (必要的话结合使用 EXSLT) 。 XPath 和 XSLT 2.0 就是第二代 XML 技术水准降低的典型例子。

(本文来源于图老师网站,更多请访问https://www.tulaoshi.com/webkaifa/)

  我和我大学时代研究操作系统设计实现的同学争论最激烈的一点是,在命名计算机符号时首字母大写(比如OneTwo)是否比下划线(如one_two) 好。当时我坚持首字母大写更好,但我逐渐认识到他是正确的。使用下划线在很大程度上改善了可读性。XML 允许在变量名中使用破折号,因此可以具有下划线那样的可读性,同时输入起来也更简单(one-two)。(关于这方面的建议位于我的另一篇文章Keep your XML clean中,请参阅 参考资料)。Harold 在Name Elements with Camel Case一节中推荐了我最不喜欢的选择。

  我认为White Space Matters是需要重点阅读的另一小节。与所有技术语言的开发人员都应该了解的其余小节的内容类似,第一部分的其他内容包括关于 DTD 设计模式的审慎建议。

  XML 体系结构

  下一部分讨论 XML 体系结构问题,前两节Make Structure Explicit through Markup和Store Metadata in Attributes探讨了很多和我在 何时使用元素,何时使用属性一文中提出的相同原则和话题。这些章节中的多数讨论和我文章中的观点是互补的。如您所料,在某些方面我有不同的看法,比如 Harold 认为坚决不能将计量单位和数字单独标记。对于卷入 XML 的每个人,Remember Mixed Content和Allow All XML Syntax章节也需要重点阅读。这些章节讲述了在 XML 处理中有时候很容易忽略的一些方面,而这些方面会影响 XML 的强大功能。Use Processing Instructions for Process-Specific Content这一节读起来非常有趣,但可能会在 XML 社区中引发争议,一些人倾向于从 XML 中去掉处理指令。我同意 Harold 的观点,处理指令可能非常有用。

  Use Namespaces for Modularity and Extensibility和Rely on Namespace URIs, Not Prefixes这两节反映了我在 小心使用 XML 名称空间和技巧 名称空间和版本控制中提出的观点(也可以在书中Version Documents, Schemas, and Stylesheets一节找到)。在下一节Don't Use Namespace Prefixes in Element Content and Attribute Values中,我们将更进一步,谈论 XML 中引发争议的另一个问题:XSLT 和其他使用 XPath 的语言在属性值中使用名称空间前缀,这种方法毫无疑问存在陷阱。但我还没有看到更高明的方法,除非重新搭建 XML 名称空间的体系结构(目前来看,这可能是一种不太现实的选择)。此外,RELAX NG 和 W3C XML Schema (WXS) 在属性中使用名称空间前缀方面存在很大差异,Harold 暗示不能将这种方法用于 RELAX NG。清单 1 是本书中使用的示例:

  清单 1. 不在属性中使用名称空间前缀编写的 RELAX NG

  

rng:element xmlns:rng="http://relaxng.org/ns/structure/1.0" name="Year" ns="http://www.example.com" rng:data type="gYear"  datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"//rng:element

  清单 2 是 清单 1的改写形式,它表明 RELAX NG 实际上并没有禁止在属性中使用名称空间前缀。

  清单 2. 清单 1 的改写形式

  

rng:element xmlns:rng="http://relaxng.org/ns/structure/1.0" xmlns:eg="http://www.example.com" name="eg:Year" rng:data type="gYear"  datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"//rng:element

  清单 2所用的方法确实需要在属性中绑定前缀。当然如果使用等价的 WXS,就没法再进行选择,只能在属性中使用前缀。RELAX NG 的好处在于它 允许避免在属性中使用名称空间前缀。因此 Harold 的观点仍然是完全合理的,不过我要澄清的是,事情比他所说的要更复杂一点。

  我发现Reuse XHTML for Generic Narrative Content这一节非常具有限制性。XML 允许使用各种不同的词汇表,这一点非常棒,我看不出有什么理由要对选择什么样的散文体词汇表进行限制。比如说,Docbook 和 TEI 在语法上都要比 XHTML 更丰富一些,在应用上也是如此。对于一般的记述性的内容,我也习惯使用 XHTML,但是我同样喜欢有其他的选择。另外一个原因和我对英语偏见的关注有关:XHTML 标签通常只对说英语的人具有直观含义。我建议为说其他语言的用户开发 XML 词汇表的人根据这些语言起草一份词汇表,使 XML 更便于用户使用。强大的 XSLT 和现成可用的 XML 转换工具确实是一个奇迹,没有人因为了完成某项任务而必须使用特定的 XML 语言。当然, 这里也应该禁止使用以迷人而最为著称的 XML 词汇表John Cowan 的Itsy Bitsy Teeny Weeny Simple Hypertext DTD (IBTWSH DTD),不过在正式的场合,我从来不使用这个 DTD,因为它坚持要求大写所有的元素类型名。

  Harold 和我经常大肆宣扬人们应该把重点放在 XML 是一种文本上,而不要过分关注数据类型化、强数据绑定或者其他诸如 XML 是某种新一轮 DBMS 替代品这类的宣传。Pretend There's No Such Thing as the PSVI一节对大量过编译(over-compication)XML 的基础设备进行了讨论:Post Schema Validation Infoset (PSVI)。这是一个用于 XML 文档的类型注释系统,诸如 WXS、XPath 2.0、XSLT 2.0 和 XQuery 的一些规范中会用到该 XML 文档,并且会将该文档用作基本的 XML 模型,而不是用作真正的 XML 文本。我希望这一节的内容能够再充实一些,提供更多的例子来完善这种观点。事实上,这个观点如此重要,我本来希望能够在Treat the Raw Text of XML as Paramount in Processing在看到一节。

  结束语

  本书的其他部分讨论了与编程和处理有关的技巧和观点,特别强调了 Java 工具和惯用法。这里不再对它们进行讨论,因为现在我关注的是核心 XML 实践和设计。 Essential XML是一部惊人的巨著,我强烈推荐这本书。但我并不同意书中的所有观点,如果我同意那样一部书中的每一个观点,那么我一定是疯了。Harold 明确列举了一些基本原则,只要认真地考虑考虑,任何读者都会成为 XML 的更好的用户。

来源:https://www.tulaoshi.com/n/20160219/1613313.html

延伸阅读
标签: Web开发
XML 作为基本数据格式无疑是成功的。但是 XML 1.0 提出的许多承诺 ― 从统一各企业间的通信方式到使 Web 更智能化 ― 都没有兑现。将 XML 用于共享的语义并因此用于共享的知识,是本专栏的主题。本文中,Ogbuji 先生介绍了迄今为止,开放应用程序组(Open Applications Group)和美国国防部(DoD)沿着这一方向,在最近发展环境中所取得的...
标签: Web开发
Uche Ogbuji 就 XML 语义透明性和 XML 知识管理方面讨论了近来所发生的事情,这其中包括 ebXML 和 RosettaNet 中的一些新的开发。 Thinking XML 专栏的前两部分讲述了语义透明性 -- 可以共享那些不受约束的 XML 尖括号和引用标记中含义。由于本文的标题直接涉及到关于 XML 近来所发生的一些事情,所以在本文中(以后还会随时有其它的)...
标签: Web开发
Uche Ogbuji 通过演示用来自现有 XML 格式的数据构成资源描述框架 (RDF)模型,开始了他的用 XML 进行的知识管理的实际探索。 如三个代码清单中所示,RDF 可用作定制 XML 的搭挡,而不仅仅用作某些数据类型的规范表示。包含代码样本的本专栏演示了如何用 RDF 方便地进行知识管理,甚至是在开发过程中相对比较晚的阶段。 虽然 W3C 将资...
标签: Web开发
教育技术领域引导着一些有趣的 XML 元数据实际应用的发展方向。在这个领域已有大量的规范、标准和开发技术,但这一切的核心是 IEEE 学习对象元数据(IEEE Learning Objects Metadata,LOM)规范。在本文中,Uche Ogbuji 介绍了 LOM,并说明它甚至会使那些与教育技术没有直接联系的人感兴趣。 计算机辅助教育学科一直充当知识管理技术的...
标签: Web开发
Uche Ogbuji 继续讨论一种 RDF 查询语言,该语言比他迄今为止所讨论的基本 API 要更为复杂得多。它是下几篇问题跟踪器专栏文章中要建立的中间件的基础。 到现在为止,在对人们可能怎样使用和查询问题跟踪器 RDF 元数据的简短讨论中,我们使用了简单而基本的查询 API。现在我们转向一种更为强大的查询语言。这将有助于编写更清晰的中间...

经验教程

68

收藏

72
微博分享 QQ分享 QQ空间 手机页面 收藏网站 回到头部