这是好的 XML 吗？

Question

我正在为一位客户工作，他一直在其网站内容中使用这种 XML 结构：

<section title="title1" layoutType="VideoViewer" xmlPath="xml/ita/title1.xml" pageTitle="extended title" previewImg=""/>

<section title="another title" layoutType="TimeLine" xmlPath="xml/ita/timeline.xml" textFile="" pageTitle="extended title for timeline"></section>

我对 XML 很陌生，但这对我来说看起来不太好。除了关闭标签的不同方式（使用 /> 自动关闭或使用 显式关闭），我认为 XML 应该更像

<section> 
  <title>title1</title> 
  <layoutType>"VideoViewer" </layoutType>
  <xmlPath>xml/ita/title1.xml </xmlPath> 
  <pageTitle>extended title</pageTitle> 
  <previewImg/>
</section>

<section>
 ...etc etc..
</section>

What do you思考？

如果它们都可以，是否有“最佳实践”？

Answer 1

只要所有元素都包含在单个根元素中，实际上就没有任何问题。

两种类型的结束标签都是可以接受的，尽管我建议所有内部没有其他标签的元素使用自结束标签。

至于结构（标签与属性），这是一个观点问题，根据定义，这两种选择都不是更好。

Answer 2

为什么您认为 XML 应该更像这样？第一个是以属性为中心的；你所提议的是以元素为中心的。虽然现在以元素为中心已经变得更常用，但以属性为中心的方法当然没有错，而且它可以使一些事情变得更清晰。

只要 XML 有命名空间，就没有问题。

Answer 3

两者都是正确的。这只是个人品味问题。

我想花一些话来阐述我的观点。

当我学习 XML 时，我了解到，当您必须存储简单的属性时，属性比子元素更可取。
简单来说，我的意思是单个、非结构化属性。

非结构化部分很简单：属性可以表示为字符串。
对于单个我的意思是你不能为属性分配超过一个值
但您可以重复相同的子元素以在父节点内创建集合/集合。

我想更清楚，但我的英语不太熟练，无法更好地解释我对这个问题的想法。

Answer 4

我认为在该示例 XML 中使用属性没有任何问题。属性有许多元素没有的限制，但也有一些显着的优点。

首先，局限性：

• 属性可能只包含简单的内容。
• 属性名称在元素内必须是唯一的。
• 根据定义，属性的顺序在 XML 中并不重要；您不能依赖 DOM 以任何特定顺序迭代或保存属性。
• 属性不是节点，这意味着在 XPath 中访问它们的方式（例如，XSLT 身份转换中使用的模式 node() | @*）和 DOM 中存在一些怪异之处（例如，在 .NET 中，XmlAttribute 派生自 XmlNode，即使属性不是节点，并且 XmlAttributeCollection 不是派生自 XmlNodeList，即使它是 XmlNode 对象的列表 - 这样做有充分的理由，但如果您是新手，这会很令人困惑）。

显着优点：

• 由于属性名称在元素内必须是唯一的，并且只能包含简单内容，因此设置和获取属性值的 DOM 方法比在元素内设置和获取值的 DOM 方法使用起来要简单得多。
• 由于属性排序并不重要，因此创建和使用属性的代码无需关心其排序。
• 由于属性可能只包含简单的内容，因此为它们编写模式定义会更容易。
• 属性的标记比元素的标记更简洁。

属性非常干净地同构到地图/字典上。您可以使用属性作为由名称/值对组成的任何数据结构的持久形式，只要可以将名称限制为有效的 XML 名称并将值限制为文本 - 并且只要在构造数据结构时不这样做无论您以什么顺序填充它。

（这可能会导致大问题。在 WPF 中，您可以使用 XAML 中的属性来存储对象属性的值，这些值在设置时会产生副作用。这样做会导致以下错误：诊断起来非常困难 - 仅仅因为您在设置 SelectedItem 之前在 XAML 中设置了 Binding 并不意味着 XamlReader 会执行此操作当它构造 XAML 表示的对象时，如果它尝试在没有 Binding 的对象上设置 SelectedItem，则会引发异常。可以整天查看 XAML，却看不出为什么会发生这种情况。）

在代码中，使用属性的好处是不言而喻的。使用 XmlDocument DOM 设置和获取元素上 foo 属性的值（在 C# 中）：

elm.SetAttribute("foo", value);

value = elm.GetAttribute("foo");

设置和获取 foo 的值code> element 在元素上：

XmlElement fooElm = (XmlElement)elm.SelectSingleNode("foo");
if (fooElm == null)
{
   elm.OwnerDocument.CreateElement("foo");
   elm.AppendChild(fooElm);
}
fooElm.InnerText = value;

XmlElement fooElm = (XmlElement)elm.SelectSingleNode("foo");
value = fooElm != null ?? fooElm.InnerText : "";

当然有更有效的方法来执行上述操作（编写辅助方法，使用 XDocument 而不是 XmlDocument，或者完全避免 DOM 并使用序列化），但使用元素本质上更加复杂。

在您的示例中，使用属性可能没问题；看起来它们代表了一个简单的名称/值对映射，顺序无关紧要。标题可能是个例外；如果您希望允许它们包含标记，您将会陷入困境。

编辑：

实际上，我相信XamlReader会按照属性在XAML中出现的顺序处理属性，因此如果您在之前设置Binding XAML 中的 SelectedItem 可能不会导致异常 - 只要 XamlReader 正在读取 XAML 的实际文本。实际上，风险在于读取和写入 XML 文档的工具会改变 XAML 文档中属性的顺序。 KaXaml 是否保留其编辑的 XAML 文档中的属性顺序？它不应该必须。

无论如何，XAML 中的解决方案很简单：不要这样做：而是

<ListBox Binding="{...}" SelectedItem="..." ... />

这样做：

<ListBox>
   <ListBox.Binding>...</ListBox.Binding>
   <ListBox.SelectedItem>...</ListBox.SelectedItem>
   ...

Answer 5

我认为你的方法更好。 xml 属性（如 title="blah"）用于定义该特定标记的属性，但是当您进入更复杂的数据结构时，您需要更多地考虑对象，其中标记的属性实际上只是定义了额外的属性数据（如数据类型、格式等）。

您的样本正朝着正确的方向前进，但这完全取决于您选择如何对数据进行建模。

例如，像“类型”这样的东西可能是该部分的适当属性（如果不确切知道你的模型是什么，就很难知道），但我假设类似的东西是合适的

Answer 6

当您公开承认您是 XML 新手时，我将为您指明 W3 Schools。至于你的问题，确实没有正确或错误的答案，两者都是合理的。这取决于您自己的具体偏好。

Answer 7

自动关闭标签很棒，但我不认为使用所有属性会被视为“最佳实践”。属性比元素有更多的限制。

来自 w3schools：

关于何时使用属性和何时使用元素没有规则。属性在 HTML 中很方便。在 XML 中，我的建议是避免它们。请改用元素。

...

使用属性的一些问题是：

* 属性不能包含多个值（元素可以）
* 属性不能包含树结构（元素可以）
* 属性不易扩展（以供将来更改）

属性难以阅读和维护。使用数据元素。使用与数据不相关的信息的属性。

使用元素。

Answer 8

我个人设计 XML 方言的风格涉及属性和元素的混合，特别注重元素。我的一般经验法则是，任何元素每行不应超过 80 个字符（不包括前导空格），因此永远不应要求换行才能舒适地阅读。

我对简短项目使用的属性非常特定于它们所附加的元素，并且没有机会扩展到多个值。我倾向于创建布尔值、数值和枚举值属性。例如，对于图像参考元素，我将设置宽度、高度和格式属性。

我将元素用于较长的值（特别是那些可以想象为任意长度的值），特别是那些稍后可能扩展到更复杂结构的元素。例如，对于图像引用元素，我会将标题、说明、描述、URL 和其他可能很长的自由文本值设为图像引用元素的子元素。

XML 应该易于人类阅读。 XML 方言应该是健壮的，并且在修改时不会破坏系统。如有疑问，请使用元素。