作者：Uche Ogbuji (uche.ogbuji@fourthought.com), IBM首席顾问, Fourthought, Inc.

简介： 采用 XML 的人遇到的老问题是，在 XML 的设计中什么时候使用元素，什么时候使用属性。对于多数设计而言，这个问题很少有绝对的答案，但是开发人员也确实体会到缺乏明确的原则来帮助他们作出决策。本文中，Uche Ogbuji 就什么放在元素中什么放在属性中提供了一些指导原则。

发布日期： 2004 年 3 月 01 日

在 SGML 中，DTD 设计的几个经常要考虑的问题也遗留给了它的分支 XML。无论使用什么 XML 模式语言，您都需要问这样的问题：

• 什么时候使用元素，什么时候使用属性来表示信息位？
• 什么时候需要对元素排队，什么时候不需要考虑顺序？
• 什么时候需要对类似元素的序列使用包装元素？

根据我和 XML 用户打交道的经验，最常见的还是第一个问题。一些情况下答案是很明确的：

• 如果涉及到的信息本身能够用元素标记，就把它放在元素中。
• 如果信息适合采用属性的形式，但可能造成同一元素中有多个同名的属性，则改用子元素。
• 如果信息需要作为类似标准 DTD 的属性类型，如 ID 、 IDREF 或 ENTITY ，则使用属性。
• 如果信息不应该进行空白字符规格化，则使用元素。（XML 处理程序规格化属性的方式可能改变属性值的原始文本。）

不幸的是，设计决策很少能进行这种明确地划分。在灰色的区域中问题仍然是如何进行正确的选择。一般的答案是 没有单一正确的答案，取决于您的最佳判断。但这对于那些希望熟悉 XML 的人来说没有多少帮助。事实上，在某些情况下即使专家也不一定意见一致，但是这并不成为不能提供在元素和属性之间选择的一些基本原则的理由。

首先，我想提出曾经听到但 不建议这样做的两条原则。我曾经听过 统统使用元素这样的建议。理由包括 属性使事情变得复杂以及 属性会影响可扩展性等等不一而足。但是如果不使用属性，就抛弃了 XML 强大功能的一个重要方面，您可能最好是改用某种分隔文本格式。

我也听说过 如果是希望在浏览器中显示的那类材料，就使用元素内容。这个原则的问题是鼓励人们根据表示考虑 XML 的内容设计，这两种问题不应混在一起。本文中也提出了一条非常相似的原则，但我是根据内容的用途而不是表示来阐述的。

本文的其他部分将提出一些指导原则，建议在元素和属性之间进行选择时采用。

推荐的指导原则

我把这些指导原则分解成了一些规则，希望能够从总体上说明元素和属性之间的选择。没有哪个规则是绝对的，可以将其作为经验规则使用，如果确实需要完全可以打破这些规则。

核心内容原则

如果认为要处理的信息属于用 XML 表示或传达的基本资料，就将其放在元素中。对于供人阅读的文档一般是指向读者传达的核心内容。对于面向机器的记录格式一般是指直接来自问题域的数据。 如果认为该信息对于传递的主要信息而言是外围的或者附属性的，或者单纯用于帮助程序处理传递的主要信息，则使用属性。这样可以避免把核心内容与辅助资料混在一起。对于面向机器的记录格式而言，这一般是指来自问题域主数据上的特定于应用程序的符号。

比如，我曾经看到过许多 XML 格式――通常是业务中自动生成的――文档标题被放在属性中。我认为，像标题这样的文档信息基本组成部分应该作为元素内容。另一方面，我也常常看到这样的情况，内部用的产品标识符被作为元素放在产品的描述记录中。其中的一些情形采用属性更合适，因为特定的内部产品代码不会成为多数读者或者文档处理人员关心的主要目标，尤其是如果 ID 非常长或者采用难以理解的格式。

您也许曾经听说过这样的一条原则， 数据使用元素，元数据使用属性。上述两段实际上表达的是同样的原则，只不过使用了更加慎重、更加明确的语言。

知名的例外

我曾经小心地指出，这些设计原则是很灵活的，肯定会找到一些理由打破这些原则。此外，您还会发现需要在不同原则的取舍之间平衡。在许多标准 XML 词汇表中，都有一些设计决策有意地违背了本文提出的一些原则。这是一些例子。

• SVG 向量路径在单个属性中用一些空格分隔的数字表示，与 结构化信息原则 相抵触。之所以这样做是因为 SVG 对简洁性的要求很迫切，但是因为这样增加了 SVG 格式处理的复杂性而受到批评。
• 许多格式都允许在属性中使用级联样式表（CSS）样式（如 XHTML 1.0 和 XSL-FO）创建复杂的样式描述，混合使用多个面（ facet）和度量单位。这样做与 结构化信息相矛盾。有趣的是，在 XHTML 2.0 中这已经不再是一个问题了，因为这个版本只允许指定一个类标记来映射到单独的 CSS，不能再使用内联的样式属性。

结构化信息原则

如果信息用结构化的形式表示，特别是如果这种结构可能需要扩展，则使用元素。另一方面， 如果信息用原子记号表示则使用属性。元素是 XML 表示的结构之所以能够扩展的动力源。差不多所有的 XML 处理工具都围绕着这一事实设计，如果能够把结构化信息正确地分解到元素中，您就会发现处理工具可以与您的设计互补，从而提高的生产率并获得了可维护性。属性用于表示元素所表达信息的简单性质。如果违背了 XML 的基本结构，把结构化信息硬塞进属性，可能表面上您似乎获得了简练和便利，但可能要付出维护的代价。

日期是一个很好的例子，它有固定的结构，并且一般作为单个标记，因此作为属性非常合理（更适合用 ISO-8601 表示）。另一方面，我发现在个人姓名的表示中这一原则令设计者感到惊奇。我曾经看到许多放在属性中的姓名，但一直坚持个人姓名应该作为元素的内容。个人姓名有着令人吃惊的可变结构，在一些文化中，如果忽略了尊称或者姓名中各个部分的先后顺序，可能会造成混乱或者冒犯他人。个人姓名也很少作为原子标记，比如有时候会按照名称有时候则按照姓氏排序。还应该指出，如果把整个姓名完全塞进一个元素的内容中或者放在属性中一样会造成问题。因此：

<customer>
  <name>Gabriel Okara</name>
  <occupation>Poet</occupation>
</customer>

比下面这种表示强不了多少：

<customer name="Gabriel Okara">
  <occupation>Poet</occupation>
</customer>

我希望在将来的一篇文章中展开讨论关于姓名的处理。

可读性原则

如果信息是供人们阅读和理解的，则使用元素。一般而言，这一原则是把没有结构的信息放在元素内容中。 如果信息主要是方便机器理解和整理，则使用属性。一般来讲，这一原则是指把不是自然语言的信息标记放到属性中。

在一些情况下，人们可以解释所表达的信息但是需要机器正确地使用它们。URL 是一个很好的例子，人们已经学会了在 Web 浏览器或者电子邮件消息中显示的 URL，但是如果没有计算机获取引用的信息，URL 通常没有多少用处。一些数据库标识符也很容易理解（尽管已经建立的数据库管理最佳实践不鼓励使用带有业务意义的 ID），但是这类 ID 通常是机器处理的小道具。基于这些原因，我建议把 URL 和 ID 放在属性中。

元素/属性绑定原则

如果需要根据另一个属性改变它的值则使用元素。XML 在属性和包含它的元素之间建立了非常强的概念联系。属性提供了那个特定元素的一些特性或者修正。XML 处理工具往往都遵循这种概念，让一个属性改变另一个属性通常是可怕的想法。比如，如果要设计一种菜单格式，而且菜单上包括菜量，您可能认为这些信息对一般的菜单格式读者而言并不重要，因此应用 核心内容原则将其作为属性。第一种尝试就是这样：

<menu>
  <menu-item portion="250 mL">
    <name>Small soft drink</name>
  </menu-item>
  <menu-item portion="500 g">
    <name>Sirloin steak</name>
  </menu-item>
</menu>

按照 结构化信息原则，您决定不把菜量和度量单位放在一个属性中，而是使用一个元素，于是选择以下格式：

<menu>
  <menu-item portion-size="250" portion-unit="mL">
    <name>Small soft drink</name>
  </menu-item>
  <menu-item portion-size="500" portion-unit="g">
    <name>Sirloin steak</name>
  </menu-item>
</menu>

现在属性 portion-unit 修正了 portion-size ，而我已经提到这不是一种好主意。元素 menu-item 上的一个属性应该修正那个元素，而不是其他的内容。应该改变这种方案而采用元素：

<menu>
  <menu-item>
    <portion unit="mL">250</portion>
    <name>Small soft drink</name>
  </menu-item>
  <menu-item>
    <portion unit="g">500</portion>
    <name>Sirloin steak</name>
  </menu-item>
</menu>

在这个例子中，我结合使用了 核心内容原则 和 可读性原则，决定把数量作为元素内容而把度量单位放在属性中。 这是一种不那么固定的情形，其他的方案可能同样合适。这种方案也与最初的决策相抵触，本来按照 核心内容原则 菜量应该放在属性中。这说明有时候这些原则可能得出互相矛盾的结论，您必须根据自己的判断具体情况具体分析。

回页首

什么也不能代替学习和实践

XML 设计对于专业人员来说是一个问题，如果要从 XML 中获益就应该有志于研究 XML 的设计原则。许多开发人员承认编写代码能够从精心的设计中获益，但是对于 XML，他们却认为只要看起来能工作就够了。我曾经看到这种区别造成了真正的、痛苦的代价。学习那些合理的 XML 设计所能带给您的经验就是要注意这个问题。对专家设计的标准 XML 词汇表进行分析，记录下您自己的设计决策，评价每个决策在后续设计中的积极和消极影响。一旦取得了经验，您的直觉就会成为做出设计决策的最重要的工具。如果您发现自己在任何重要的领域使用 XML，您的努力也就获得了回报。

我计划在将来的文章中像本文一样继续讨论 XML 的设计原则。我还将在我的 Thinking XML 专栏 中继续简要地触及 XML 设计原则。如果您对 XML 设计有什么想法和问题，请在 Thinking XML讨论论坛 上发表。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
• 看一看知名的 Cover Pages，它提供了关于该主题的一些信息，集中在以下页面上： SGML/XML: Elements versus attributes, 1998 年 4 月和 SGML/XML: Using Elements and Attributes。
• 阅读 Elliotte Rusty Harold 的 Effective XML （Addison-Wesley, 2003）。根据我的体会，作者非常精通 XML 设计和最佳实践。您可以在线阅读部分章节，包括“ Store metadata in attributes”和“ Make structure explicit through markup”，它们都与本文的内容有直接的关系。
• 可以在 developerWorks XML 专区 找到更多 XML 资源。特别是在我的 Thinking XML 专栏中有时也触及一些问题。您还可以在 XML 实用技巧中找到许多这样的文章。
• IBM WebSphere Studio Application Developer 是一种支持使用各种不同的技术（如 XML、JSPTM、sevlet、HTML、Web 服务、数据库和 EJB ）构建多种应用程序的开发工具。
• 在 developerWorks Developer Bookstore上可以找到大量关于 XML 的书籍。
• 了解如何才能成为一名 IBM 认证的 XML 及相关技术的开发人员。

关于作者

Uche Ogbuji 是 Fourthought Inc.的顾问兼创始人，该公司是专为企业知识管理提供 XML 解决方案的软件供应商和咨询公司。 Fourthought 开发了 4Suite，这是一个用于 XML、RDF 和知识管理应用程序的开放源代码平台。Ogbuji 先生也是 VersaRDF 查询语言的主要开发者。他是一位出生于尼日利亚的计算机工程师和作家，在美国科罗拉多的博耳德生活和工作。可以通过 uche.ogbuji@fourthought.com和 Ogbuji 先生联

您可能也喜欢：
如何设计出色的ppt	数据库基准测试系统通用模型设计	Rokey-设计贴士	PostGreSQL多版本实现中的几个问题
无觅

写个评论

美国国债是如何形成的？这要从美元这种债务货币说起。所谓债务货币，就是指以举债的方式获得信用，并基于此信用发行的货币。

简单地说，美国向他国借来各种信用抵押品（黄金、货币、产品），然后以此作为抵押，发行美元。到一定的期限时，归还此抵押。

基本上，美国当前有多少国债，它便发行了多少美元。

那么中国购买了10000亿美元的美债，究竟意味着什么？

假设当前人民币兑换美元是6：1，中国一次性购入10000亿美元的美债，那么意味着中国拿来60000亿人民币，交给美国。

美国拿到这60000亿人民币以后，它就发行10000亿美元的新货币。

此时假如中国出口商品到美国，那么，美国就可以使用这10000亿新美元进行支付购买。

表面上看，是美国使用中国给的钱买中国的东西，中国亏大了。

实际上，中国确实是亏的。不过没有亏在这里。

我们继续上面的场景。假如我们卖了10000亿美元的产品给美国，此时我们将持有这10000亿美元，然后我们又从美国买了10000亿美元的电子产品。

这时候发生了什么？中美两国交换了价值10000亿美元的产品，此外什么都没有发生。

美元在这里，就是起到了一个最基本的交易手段作用。

那么我们拿给美国的60000亿人民币呢？美国会定期归还本金和利息，到一个期限后还清。

也就是说，我们在一段时间内抵押了60000亿人民币给美国，美国回报给我们一定的利息——借人民币，还美元。

这桩买卖划不划算，取决于利息的高低和美元相对于人民币是否贬值。

那么，为什么美国要支付利息给中国？理由是中国为美国提供了信用，进而使得美国可以发行美元以提高交易效率。也就是说，所有使用美元的人、公司和经济体实际上都受益于中国提供的信用，也就是说所有使用美元的人都应该支付此利息。而事实上，只有美国为此支付利息。因此，理论上当美元发行量够大的时候，美国每年的GDP会还不起美债的利息，然后美国会破产。

当然以上都是理想情况，就是说美国每一次美元发行都有相应的抵押品，而不是随意发行美元。

但实际上，美国做不到这一点。大名鼎鼎的”量化宽松“政策，使得美国可以光明正大地凭空印钞，然后美元贬值，从而将利息压力直接转嫁给别国——包括中国自己。这个东东，术语叫做”铸币税“。

综上所说，基本上你可以认为美国是借债少给利息、不给利息，甚至连本金都给你缩水的类型。这才是中国持有美国国债亏本的地方。当然如果某一天美元贬值到0，那中国也就血本无归了，这就真的亏大了。

货币发行权是最高的经济权力，这话一点都没差。

您可能也喜欢：
从Google购物关键字看用户网上购物习惯	地瓜熊老6的囧生活（9）	地瓜熊老6的囧生活（6）	所谓黑丝，也就那么回事儿
无觅

写个评论

在此我们假设商品只有一种，那么具有良好价值尺度功能的货币，在任何时间点购得的商品数量一致。

这种假设意味着货币既不能升值也不能贬值。

货币体系的可行性定义：在满足良功能的前提下，保持货币体系稳定。

金本位货币的定义。所谓金本位货币，是指以黄金为抵押发行的货币，货币可以按照一定比例兑换抵押物。

金本位货币的可行性定义：满足良功能，同时抵押品不会被兑换完。

Question：

金本位货币是否具有可行性？如果是，那么其限制条件是什么？

My Answer：

假设以100单位的黄金作为抵押，发行10000个单位的货币，同时社会总财富（含抵押品）为10100单位。

此时一单位货币兑换一单位商品，或兑换0.01单位的黄金。我们假定此时是稳定状态，即0.01单位的黄金，其价值==1单位商品。此时如果所有人将货币兑换为黄金，则货币作废，同时黄金全部被兑换，两清。

一年后，社会总财富增长10000单位，到20100单位。

此时如果增发10000个单位货币。一单位货币将仍兑换一单位商品，实现稳定币值。但一单位货币只能兑换0.005单位黄金。即1单位黄金==2单位商品。假设社会总财富预期仍将增长，则可认为当下黄金价值被低估，持有黄金将获益，因此黄金将被大量兑换，货币体系无法维持。

如果增发10100个单位的货币，则单位货币能兑换的商品不足一单位，意味着货币贬值。

金本位货币的可行性不足。在经济增长的前提下，要么持续贬值，要么体系崩溃。

债务货币的定义。债务货币是指通过举债方式，获得抵押品，并据此发行的货币。同样，货币可以兑换抵押品。债务货币不同于金本位的特点有二：一是债务规模可变，二是债务可能需要付利息。注意，这里如果抵押品不是黄金等只有价值而基本无使用价值的商品，则造成使用价值的损失。

Question：

债务货币是否具有可行性？

My Answer：

根据借债对象的不同，分为两种。一种是在本经济体内借债，一种是对外部经济体借债。

根据借债规模的不同，分为两种。一种是债务规模小于社会总财富，一种是债务规模等于社会总财富。

对内借债且债务规模等于社会总财富。此方案实际无法实现——一个经济体不可能将其所有财富用于抵押。不过实际上不采用抵押方式，而采用强制力保证货币的兑换，却是可行的，这就是法币，这里不赘述。

对外借债且债务规模等于社会总财富。此情况下肯定要付给借债方利息。因为抵押品由外部提供，所以币值稳定肯定可以保证（只需按社会总财富提供即可，当然这里假设借债方的抵押品足够）。假设借债方规模无限的情况下，此体系同样不会崩溃。理论上此体系可行。但是现实中基本不可行——抵押品不可能太多，利率常常超过社会财富增长速度，从而导致经济负增长。

对内借债且债务规模小于社会总财富。假设初期为平衡状态，即社会财富的一半被抵押。假设社会总财富20000，抵押10000，使用中10000，发行10000货币。一年后，使用中财富增长20%，即社会总财富为22000。此时如增发2000货币，即总流通货币12000，可维持币值稳定，且不增加举债规模，但这同金本位一样，会引起抵押品被挤兑。如增发1000货币，同时增加1000举债，则可维持币值稳定——但同样不可行，因为这样的话举债规模始终占社会总财富的一般，浪费太大。

对外借债且债务规模小于社会总财富。这个情况没什么意义，抵押失效。

债务货币和其类似体中，只有法币是理论上可行的。

您可能也喜欢：
抗通胀，不收货币万万不能	CQRS体系结构模式	Internet Rule No. 34	地瓜熊老6的囧生活（15）
无觅

写个评论