设计 XML 模式的最佳实践是什么？

What are best practices for designing XML schemas?

提问by evizaer

As an amateur software developer (I'm still in academia) I've written a few schemas for XML documents. I routinely run into design flubs that cause ugly-looking XML documents because I'm not entirely certain what the semantics of XML exactly are.

作为一名业余软件开发人员（我还在学术界），我为 XML 文档编写了一些模式。我经常遇到导致 XML 文档难看的设计失误，因为我不完全确定 XML 的语义到底是什么。

My assumptions:

我的假设：

<property> value </property>

property = value

财产=价值

<property attribute="attval"> value </property>

A property with a special descriptor, the attribute.

具有特殊描述符的属性，即属性。

<parent>
  <child> value </child>
</parent>

The parent has a characteristic "child" which has the value "value."

父级具有特征值“值”的“子级”。

<tag />

"Tag" is a flag or it directly translates to text. I'm not sure on this one.

“标签”是一个标志或它直接转换为文本。我不确定这一点。

<parent>
  <child />
</parent>

"child" describes "parent." "child" is a flag or boolean. I'm not sure on this one, either.

“孩子”描述“父母”。“child”是一个标志或布尔值。我也不确定这一点。

Ambiguity arises if you want to do something like representing cartesian coordinates:

如果你想做一些像表示笛卡尔坐标这样的事情，就会出现歧义：

<coordinate x="0" y="1 />

<coordinate> 0,1 </coordinate>

<coordinate> <x> 0 </x> <y> 1 </y> </coordinate>

Which one of those is most correct? I would lean towards the third based upon my current conception of XML schema design, but I really don't know.

其中哪一项最正确？根据我目前对 XML 模式设计的概念，我倾向于第三种，但我真的不知道。

What are some resources that succinctly describe how to effectively design xml schemas?

有哪些资源可以简洁地描述如何有效地设计 xml 模式？

采纳答案by Dimitre Novatchev

See the tutorial:

看教程：

• "XML Schemas: Best Practices" by Roger Costello.

• “ XML 模式：最佳实践”，作者Roger Costello。

I also recommend:

我也推荐：

• Priscilla Walmsley's book "Definitive XML Schema".

• Jeni Tennison's XML Schema pages

• Priscilla Walmsley的书“Definitive XML Schema”。

• Jeni Tennison的XML 模式页面

回答by C. Dragon 76

One general (but important!) recommendation is never to store multiple logical pieces of data in a single node (be it a text node or an attribute node). Otherwise, you end up needing your own parsing logic on top ofthe XML parsing logic you normally get for free from your framework.

一个通用的（但很重要！）建议永远不要在单个节点（无论是文本节点还是属性节点）中存储多个逻辑数据片段。否则，你最终需要自己的分析逻辑之上的XML解析逻辑，你通常从框架免费获得。

So in your coordinate example, <coordinate x="0" y="1" />and <coordinate> <x>0</x> <y>1</y> </coordinate>are both reasonable to me.

因此，在你的坐标例如， <coordinate x="0" y="1" />并且 <coordinate> <x>0</x> <y>1</y> </coordinate>都是合理的，我。

But <coordinate> 0,1 </coordinate>isn't very good, because it's storing two logical pieces of data (the X-coordinate and the Y-coordinate) in a single XML node—forcing the consumer to parse the data outsideof their XML parser. And while splitting a string by a comma is pretty simple, there are still some ambiguities like what happens if there's an extra comma at the end.

但<coordinate> 0,1 </coordinate>不是很好，因为它将两个逻辑数据片段（X 坐标和 Y 坐标）存储在单个 XML 节点中——迫使使用者在其 XML 解析器之外解析数据。虽然用逗号分割字符串非常简单，但仍然存在一些歧义，例如如果末尾有一个额外的逗号会发生什么。

回答by 6eorge Jetson

I agree w/ cdragon's advice below to avoid option #2. The choice between #1 & #3 is largely a matter of style. I like to use attributes for what I consider to be attributes of the entity, and elements for what I consider to be data. Sometimes, it's hard to classify. Nonetheless, neither are "wrong".

我同意下面 cdragon 的建议，以避免选项 #2。#1 和 #3 之间的选择很大程度上取决于风格。我喜欢将属性用于我认为是实体的属性，而元素则用于我认为是数据的内容。有时，很难分类。尽管如此，两者都没有“错”。

And while we're on the topic of schema design, I'll add my two cents regarding my preferred level of (maximum) reuse (of both elements and types), which can also facilitate external "logical" referencing of these entities in, say, a data dictionary stored in a database.

当我们讨论模式设计的主题时，我将添加关于我首选的（最大）重用级别（元素和类型）的两分钱，这也可以促进这些实体的外部“逻辑”引用，比如说，存储在数据库中的数据字典。

Note that while the "Garden of Eden" schema pattern offers the maximum reuse, it also involves the most work. At the bottom of this post, I've provided links to the other patterns covered in the blog series.

请注意，虽然“伊甸园”模式提供了最大的重用，但它也涉及最多的工作。在这篇文章的底部，我提供了指向博客系列中涵盖的其他模式的链接。

• The Garden of Eden approach http://blogs.msdn.com/skaufman/archive/2005/05/10/416269.aspx

•伊甸园方法http://blogs.msdn.com/skaufman/archive/2005/05/10/416269.aspx

Uses a modular approach by defining all elements globally and like the Venetian Blind approach all type definitions are declared globally. Each element is globally defined as an immediate child of the node and its type attribute can be set to one of the named complex types.

通过全局定义所有元素使用模块化方法，并且像百叶窗方法一样，所有类型定义都是全局声明的。每个元素都被全局定义为节点的直接子元素，并且其类型属性可以设置为指定的复杂类型之一。

<?xml version="1.0" encoding="UTF-8"?> 
<xs:schema targetNamespace="TargetNamespace" xmlns:TN="TargetNamespace" 
  xmlns:xs="http://www.w3.org/2001/XMLSchema" 
  elementFormDefault="qualified" attributeFormDefault="unqualified"/> 
<xs:element name="BookInformation" type="BookInformationType"/> 
  <xs:complexType name="BookInformationType"/> 
    <xs:sequence> 
      <xs:element ref="Title"/> 
      <xs:element ref="ISBN"/> 
      <xs:element ref="Publisher"/> 
      <xs:element ref="PeopleInvolved" maxOccurs="unbounded"/> 
    </xs:sequence> 
  </xs:complexType> 
  <xs:complexType name="PeopleInvolvedType"> 
    <xs:sequence> 
      <xs:element name="Author"/> 
    </xs:sequence> 
  </xs:complexType> 
  <xs:element name="Title"/> 
  <xs:element name="ISBN"/> 
  <xs:element name="Publisher"/> 
  <xs:element name="PeopleInvolved" type="PeopleInvolvedType"/> 
</xs:schema>

The advantage of this approach is that the schemas are reusable. Since both the elements and types are defined globally both are available for reuse. This approach offers the maximum amount of reusable content. The disadvantages are the that the schema is verbose. This would be an appropriate design when you are creating general libraries in which you can afford to make no assumptions about the scope of the schema elements and types and their use in other schemas particularly in reference to extensibility and modularity.

这种方法的优点是模式是可重用的。由于元素和类型都是全局定义的，因此它们都可以重用。这种方法提供了最大数量的可重用内容。缺点是模式冗长。当您创建通用库时，这将是一个合适的设计，您可以在其中对模式元素和类型的范围以及它们在其他模式中的使用做出任何假设，特别是在参考可扩展性和模块化方面。

Since every distinct type and element has a single global definition, these canonical particles/components can be related one-to-one to identifiers in a database. And while it may at first glance seem like a tiresome ongoing manual task to maintain the associations between the textual XSD particles/components and the database, SQL Server 2005 can in fact generate canonical schema component identifiers via the statement

由于每个不同的类型和元素都有一个单一的全局定义，这些规范粒子/组件可以与数据库中的标识符一对一相关。乍一看，维护文本 XSD 粒子/组件与数据库之间的关联似乎是一项令人厌烦的手动任务，但 SQL Server 2005 实际上可以通过语句生成规范架构组件标识符

CREATE XML SCHEMA COLLECTION

http://technet.microsoft.com/en-us/library/ms179457.aspx

http://technet.microsoft.com/en-us/library/ms179457.aspx

Conversely, to construct a schema from the canonical particles, SQL Server 2005 provides the

相反，为了从规范粒子构建架构，SQL Server 2005 提供了

SELECT xml_schema_namespace function

http://technet.microsoft.com/en-us/library/ms191170.aspx

http://technet.microsoft.com/en-us/library/ms191170.aspx

ca·non·i·cal Related to Mathematics. (of an equation, coordinate, etc.) "in simplest or standard form" http://dictionary.reference.com/browse/canonical

ca·non·i·cal 与数学有关。（方程、坐标等）“以最简单或标准的形式” http://dictionary.reference.com/browse/canonical

Other, easier to construct, but less resuable/more "denormalized/redundant" schema patterns include

其他更容易构建但不太可重用/更“非规范化/冗余”的模式模式包括

• The Russian Doll approach http://blogs.msdn.com/skaufman/archive/2005/04/21/410486.aspx

•俄罗斯娃娃方法http://blogs.msdn.com/skaufman/archive/2005/04/21/410486.aspx

The schema has one single global element - the root element. All other elements and types are nested progressively deeper giving it the name due to each type fitting into the one above it. Since the elements in this design are declared locally they will not be reusable through the import or include statements.

模式有一个单一的全局元素——根元素。所有其他元素和类型都逐渐嵌套得更深，因为每种类型都适合它上面的类型。由于此设计中的元素是在本地声明的，因此无法通过 import 或 include 语句重用。

• The the Salami Slice approach http://blogs.msdn.com/skaufman/archive/2005/04/25/411809.aspx

•意大利腊肠切片方法http://blogs.msdn.com/skaufman/archive/2005/04/25/411809.aspx

All elements are defined globally but the type definitions are defined locally. This way other schemas may reuse the elements. With this approach, a global element with its locally defined type provide a complete description of the elements content. This information 'slice' is declared individually and then aggregated back together and may also be pieced together to construct other schemas.

所有元素都是全局定义的，但类型定义是本地定义的。这样其他模式可以重用元素。通过这种方法，具有其本地定义类型的全局元素提供了元素内容的完整描述。该信息“切片”被单独声明，然后聚合在一起，也可以拼凑在一起以构建其他模式。

• The Venetian Blind approach http://blogs.msdn.com/skaufman/archive/2005/04/29/413491.aspx

•盲人方法 http://blogs.msdn.com/skaufman/archive/2005/04/29/413491.aspx

Similar to the Russian Doll approach in that they both use a single global element. The Venetian Blind approach describes a modular approach by naming and defining all type definitions globally (as opposed to the Salami Slice approach which declares elements globally and types locally). Each globally defined type describes an individual "slat" and can be reused by other components. In addition, all the locally declared elements can be namespace qualified or namespace unqualified (the slats can be "opened" or "closed") depending on the elementFormDefault attribute setting at the top of the schema.

类似于俄罗斯娃娃的方法，因为它们都使用单个全局元素。Venetian Blind 方法通过全局命名和定义所有类型定义来描述模块化方法（与 Salami Slice 方法相反，后者在全局声明元素并在本地声明类型）。每个全局定义的类型描述一个单独的“slat”并且可以被其他组件重用。此外，根据架构顶部的 elementFormDefault 属性设置，所有本地声明的元素都可以是命名空间限定的或命名空间非限定的（板条可以“打开”或“关闭”）。

回答by Greg Beech

XML is somewhat subjective in terms of design - I don't think there are exact guidelines for how the elements and attributes should be laid out, but I tend to go with using elements to represent 'things' and attributes to represent singular attributes/properties of them.

XML 在设计方面有些主观 - 我不认为应该如何布置元素和属性有确切的指导方针，但我倾向于使用元素来表示“事物”和属性来表示单个属性/属性其中。

In terms of the coordinates example either would be perfectly acceptable, but my inclination would be to go with <coordinate x="" y=""/>because it is somewhat more terse, and makes the document a little more readable if you have many of them.

就坐标示例而言，两者都是完全可以接受的，但我倾向于使用<coordinate x="" y=""/>它，因为它更简洁一些，并且如果您有很多这样的文档，则会使文档更具可读性。

The most important thing, though, is the namespace of the schema. Make sure that (a) you have one, and (b) you have a version in there so you can change things in the future and issue a new version. Versions may be either dates or numbers, e.g.

不过，最重要的是架构的命名空间。确保 (a) 你有一个，并且 (b) 你有一个版本，这样你就可以在未来改变事情并发布一个新版本。版本可以是日期或数字，例如

http://company.com/2008/12/something/somethingelse/
urn:company-com:2008-12:something:somethingelse

http://company.com/v1/something/somethingelse/
urn:company-com:v1:something:somethingelse

回答by ddaa

I do not know any good learning resource about how to design XML document models (schemas are just a formal way of specifying document models).

我不知道关于如何设计 XML 文档模型的任何好的学习资源（模式只是指定文档模型的正式方式）。

In my opinion, one crucial insight to XML is that it is not a language: it is a syntax. And each document model is a separate language.

在我看来，对 XML 的一个重要见解是它不是一种语言：它是一种语法。每个文档模型都是一种单独的语言。

Different cultures will each use XML in their own special way. Even within W3C specifications you can smell Lisp in dash-separated-names of XSLT, and Java in the camelCaseNames of XML Schema. Similarly, different application domains will call for different XML idioms.

不同的文化都会以自己的特殊方式使用 XML。即使在 W3C 规范中，您也可以在 XSLT 的破折号分隔名称中闻到 Lisp 的味道，在 XML Schema 的驼峰式名称中可以闻到 Java 的味道。同样，不同的应用程序域将调用不同的 XML 习惯用法。

Narrative document models such as HTMLor DocBooktend to put printable text in text nodes and metadata in element names and attributes.

HTML或DocBook等叙述性文档模型倾向于将可打印文本放在文本节点中，并将元数据放在元素名称和属性中。

More object-oriented document models such as SVGmake little or no use of text nodes and instead only use elements and attributes.

更多面向对象的文档模型（如SVG）很少或不使用文本节点，而是仅使用元素和属性。

My personal rules of thumb for document model design go something like this:

我个人的文档模型设计经验法则是这样的：

• If it is the sort of the free-from tag soup that requires mixed content, use HTML and DocBook as sources of inspiration. The other rules are only relevant otherwise.
• If a value is going to be composite or hierarchical, use elements. XML data should require no further parsing, except for established idioms such as IDREFS which are simple space-separated sequences.
• If a value may need to occur more than once, use elements.
• If a value may need to be refined further, or enriched later, use elements.
• If a value is clearly atomic (boolean, number, date, identifier, simple label), and may occur at most once, then use an attribute.

• 如果是那种需要混合内容的免标签汤，使用 HTML 和 DocBook 作为灵感来源。其他规则仅在其他方面相关。
• 如果值将是复合的或分层的，请使用元素。XML 数据不需要进一步解析，除了已建立的习惯用法，例如 IDREFS，它们是简单的空格分隔序列。
• 如果一个值可能需要多次出现，请使用元素。
• 如果某个值可能需要进一步细化或稍后丰富，请使用元素。
• 如果一个值显然是原子的（布尔值、数字、日期、标识符、简单标签），并且最多可能出现一次，则使用属性。

Another way to say it could be:

另一种说法可能是：

• If it's narrative, it's not object oriented.
• If it's object oriented, model objects as elements and atomic attributes as attributes.

• 如果它是叙述性的，则它不是面向对象的。
• 如果它是面向对象的，则将对象建模为元素，将原子属性建模为属性。

EDIT: Some people seem to like to entirely forgo attributes. There's nothing wrongwith it, but I dislike it as it bloats documents and make them unnecessary hard to read and write by hand.

编辑：有些人似乎喜欢完全放弃属性。它没有任何问题，但我不喜欢它，因为它会使文档膨胀并使手动读写变得不必要。

回答by neves

I was designated to write a bunch of XML schemas to integrate my company systems with our clients. I've designed a dozen of them more than 10 years ago and saw that a lot of extension features in the specification didn't work well in practice. Before designing the new ones, I've searched for the current best practices (and arrived here!).

我被指定编写一堆 XML 模式来将我的公司系统与我们的客户集成。我在 10 多年前设计了十几个，发现规范中的许多扩展功能在实践中效果不佳。在设计新的之前，我已经搜索了当前的最佳实践（并到达了这里！）。

Some of the tips above are useful, but I didn't like almost all references. The best place with design recommendations that I found were from Microsoft.

上面的一些技巧很有用，但我不喜欢几乎所有的参考。我找到的最好的设计建议来自微软。

The best reference is XML Schema Design Patterns: Avoiding Complexity. Here you will find this sane advice:

最好的参考是XML 模式设计模式：避免复杂性。在这里你会找到这个明智的建议：

it seems that many schema authors would be best served by understanding and utilizing an effective subset of the features provided by W3C XML Schema instead of attempting to comprehend all of the esoteric and minutiae of the language.

通过理解和利用 W3C XML Schema 提供的有效功能子集，而不是试图理解该语言的所有深奥和细节，似乎可以为许多模式作者提供最好的服务。

and give detailed explanations of the following guidelines:

并详细说明以下准则：

• Why you should use global and local element declarations
• Why you should use global and local attribute declarations
• Why you should understand how XML namespaces affect the W3C XML Schema
• Why you should always set elementFormDefault to "qualified"
• Why you should use attribute groups
• Why you should use model groups
• Why you should use the built-in simple types
• Why you should use complex types
• Why you should not use notation declarations
• Why you should use substitution groups carefully
• Why you should favor key/keyref/unique over ID/IDREF for identity constraints
• Why you should use chameleon schemas carefully
• Why you should not use default or fixed values especially for types of xs:QName
• Why you should use restriction and extension of simple types
• Why you should use extension of complex types
• Why you should use restriction of complex types carefully
• Why you should use abstract types carefully
• Do use wildcards to provide well-defined points of extensibility
• Do not use group or type redefinition

• 为什么应该使用全局和局部元素声明
• 为什么应该使用全局和局部属性声明
• 为什么您应该了解 XML 名称空间如何影响 W3C XML Schema
• 为什么您应该始终将 elementFormDefault 设置为“合格”
• 为什么应该使用属性组
• 为什么应该使用模型组
• 为什么你应该使用内置的简单类型
• 为什么应该使用复杂类型
• 为什么不应该使用符号声明
• 为什么要谨慎使用替换组
• 为什么你应该偏爱 key/keyref/unique 而不是 ID/IDREF 作为身份约束
• 为什么应该谨慎使用变色龙模式
• 为什么不应该使用默认值或固定值，尤其是对于 xs:QName 类型
• 为什么你应该使用简单类型的限制和扩展
• 为什么你应该使用复杂类型的扩展
• 为什么应该谨慎使用复杂类型的限制
• 为什么要谨慎使用抽象类型
• 务必使用通配符来提供明确定义的可扩展点
• 不要使用组或类型重新定义

My advice about their advice is that when they say "use carefully", you should simply avoid it. My impression is that the Schema specification were not written by software developers. They tried to use some Object Orientation concepts but did a mess of it. A lot of the extension mechanisms are useless or extremely verbose. I don't really understand how someone could have invented the restriction of complex types.

我对他们的建议的建议是，当他们说“小心使用”时，您应该避免使用它。我的印象是 Schema 规范不是由软件开发人员编写的。他们试图使用一些面向对象的概念，但做得一团糟。许多扩展机制是无用的或极其冗长的。我真的不明白有人怎么会发明复杂类型的限制。

Two more nice articles in this site are:

本网站还有两篇不错的文章是：

• Schema Design Patterns: Dealing With Change
• XML Schema Design Patterns: Is Complex Type Derivation Unnecessary?

• 模式设计模式：应对变化
• XML Schema 设计模式：复杂类型派生是不必要的吗？

And one tip that is pervasive is to specify your schemas with something different than the official specification. Relax NG looks the most favored specification language. Unfortunately you will loose one of the best features of it that is the standardization.

一个普遍存在的技巧是使用与官方规范不同的内容来指定您的模式。Relax NG 看起来是最受青睐的规范语言。不幸的是，您将失去它的最佳功能之一，即标准化。

回答by Hans-Peter St?rr

In our Java-projects we are often using JAXBto automatically parse XML and transform it into an object structure. I guess for other languagues you'll have something similar. A suitable generator can create automatically the object structure in your chosen programming language. This makes processing of XML often much easier, while still having a portable XML representation for the communication between systems.

在我们的 Java 项目中，我们经常使用JAXB来自动解析 XML 并将其转换为对象结构。我想对于其他语言，你会有类似的东西。合适的生成器可以使用您选择的编程语言自动创建对象结构。这使得 XML 的处理通常容易得多，同时仍然具有用于系统之间通信的可移植 XML 表示。

If you do use such an automatic mapping, you will find this constrains the schema much - <coordinate> <x> 0 </x> <y> 1 </y> </coordinate>is the way to go unless you want to do special magic in the translation. You will end up with a Class Coordinatewith two attributes xand ywith the appropriate type as declared in the schema.

如果您确实使用了这样的自动映射，您会发现这会极大地限制模式 -<coordinate> <x> 0 </x> <y> 1 </y> </coordinate>除非您想在翻译中做特殊的魔术，否则这是要走的路。您将最终得到一个Coordinate具有两个属性x和y模式中声明的适当类型的类。

回答by Jeff Yates

When designing an XML-based format, it's often good to think about what you're representing. Try mocking some XML data that fits the purpose you intend. Once you've got something you're satisfied with that meets your requirements, develop the schema to validate it.

在设计基于 XML 的格式时，最好考虑一下您所表示的内容。尝试模拟一些符合您预期目的的 XML 数据。一旦你得到了满足你要求的东西，开发模式来验证它。

When desiging a format, I tend to use elements for holding data content and attributes for applying characteristics to the data like an id, a name, a type, or some other metadata about the data an element contains.

在设计格式时，我倾向于使用元素来保存数据内容和属性来将特征应用于数据，例如 id、名称、类型或与元素包含的数据有关的一些其他元数据。

In that regard, an XML representation for coordinates might be:

在这方面，坐标的 XML 表示可能是：

<coordinate type="cartesian">
  <ordinate name="x">0</ordinate>
  <ordinate name="y">1</ordinate>
</coordinate>

This caters for different coordinate systems. If you knew they'd always be cartesian, a better implementation might be:

这迎合了不同的坐标系。如果你知道它们总是笛卡尔，更好的实现可能是：

<coordinate>
  <x>0</x>
  <y>1</y>
</coordinate>

Of course, the latter could lead to a more verbose schema as each element type would need declaring (though I'd hope a complex type was defined to actually do the hard work for these elements).

当然，后者可能会导致更冗长的模式，因为每个元素类型都需要声明（尽管我希望定义一个复杂类型来实际为这些元素完成艰苦的工作）。

Just as in programming, there are often multiple ways of achieving the same ends, but there is no right and wrong in many situations, just better and worse. The important thing is to remain consistent and try to be intuitive so that when others look at your schema, they can understand what you were trying to achieve.

就像在编程中一样，通常有多种方法可以达到相同的目的，但在很多情况下没有对与错，只有更好和更坏。重要的是保持一致并尝试直观，这样当其他人查看您的架构时，他们可以理解您想要实现的目标。

You should always version your schemas and ensure that XML written against your schema indicates it as such. If you don't properly version the XML then making addendums to the schema while supporting XML written to the older schema will be much more difficult.

您应该始终对您的模式进行版本控制，并确保针对您的模式编写的 XML 表明它是这样的。如果您没有正确地对 XML 进行版本控制，那么在支持将 XML 写入旧模式的同时对模式进行增补将会困难得多。

回答by shahkalpesh

I guess, it depends on how complex or simple the structure is.
I will make x and y as attribute, unless x and y have their own details

我想，这取决于结构的复杂程度或简单程度。
我将 x 和 y 作为属性，除非 x 和 y 有自己的详细信息

You can look at HTML or any other form of markup, which is used to define things (XAML in case of WPF, MXML in case of flash) to understand, why something is chosen as attribute as against a child node)

您可以查看 HTML 或任何其他形式的标记，这些标记用于定义事物（WPF 中的 XAML，Flash 中的 MXML）以了解为什么选择某些内容作为针对子节点的属性）

if x and y are not to be repeated, they can be attributes.

如果 x 和 y 不重复，它们可以是属性。

Lets say co-ordinates has multiple x and y, I guess xml doesnt allow multiple attributes with same name for a node. In that case, you will have to use child nodes.

假设坐标有多个 x 和 y，我猜 xml 不允许一个节点有多个具有相同名称的属性。在这种情况下，您将不得不使用子节点。

回答by BQ.

There's nothing inherently wrong with using an element or sub-element for every value you'd like to represent.

为您想要表示的每个值使用元素或子元素并没有本质上的错误。

The main consideration is that sometimes it's cleaner to use an attribute. Since an element can only have one attribute of a given name, you're stuck with a 1:1 cardinality. If you're representing the data as a child element, you can use whatever cardinality you'd like (or be open to extending it later).

主要考虑是有时使用属性更干净。由于一个元素只能有一个给定名称的属性，因此您只能使用 1:1 的基数。如果您将数据表示为子元素，则可以使用任何您喜欢的基数（或者以后可以扩展它）。

Rob Wells' response above is right: it depends on the relationships you're trying to model.

Rob Wells 上面的回答是正确的：这取决于您尝试建模的关系。

Any time there's clearly never going to be anything but a 1:1 relationship, an attribute may be cleaner.

任何时候，除了 1:1 的关系外，显然永远不会有任何东西，属性可能会更清晰。