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很陌生，但这对我来说并不好看。除了关闭标记的不同方式（使用/>自动关闭或使用</section>显式关闭）我会认为XML应该更像

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

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

您怎么看？

如果他们都没问题，是否有“最佳实践”？

Answer 1

只要所有元素都包含在一个根元素中，就没有任何实际的错误。

任何一种结束标记都是可以接受的，虽然我建议在其中没有其他标记的所有元素中使用自闭标记。

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

Answer 2

为什么你认为XML应该更像那样？第一个是以属性为中心的;你提出的是以元素为中心的。虽然现在以元素为中心已经变得越来越普遍，但以属性为中心的方法肯定没有错，它可以使一些事情变得更加清晰。

只要XML有一个命名空间，那就没有错。

Answer 3

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

我会在我的观点上花一些话。

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

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

我想更清楚但是我不太精通英语来更好地解释我对这个问题的想法。

Answer 4

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

首先，限制：

属性可能只包含简单内容。
属性名称在元素中必须是唯一的。
根据定义，XML中的属性排序并不重要;您不能依赖DOM以任何特定顺序迭代或保存属性。
属性不是节点，这意味着在XPath中访问它们的方式存在一些怪癖（例如，XSLT标识转换中使用的模式node() | @*）和DOM中（例如在.NET中， XmlAttribute XmlNode派生自XmlAttributeCollection，即使属性不是节点，XmlNodeList 也派生自XmlNode，即使它是Binding的列表{1}}对象 - 这有很好的理由，但是如果你是新手的话会很混乱。）

显着优势：

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

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

（这可能会导致很大的问题。在WPF中，您可以使用XAML中的属性来存储在设置时具有副作用的对象属性的值。这样做会导致非常难以诊断的错误 - 只是因为在设置SelectedItem之前在XAML中设置XamlReader并不意味着SelectedItem在构造XAML所代表的对象时会发生这种情况，并且如果它试图设置Binding对象没有foo，但它会抛出异常。你可以整天看看你的XAML而不知道为什么会发生这种情况。）

在代码中，使用属性的好处是不言而喻的。使用XmlDocument DOM（在C＃中）设置和获取元素的elm.SetAttribute("foo", value); value = elm.GetAttribute("foo");属性的值：

foo

在元素上设置并获取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而不是XamlReader，或完全避免使用DOM并使用序列化），但使用它本身就更复杂元件。

在您的示例中，使用属性可能没问题;它看起来像是一个简单的名称/值对映射，具有无关紧要的排序。例外情况可能是标题;如果允许它们包含标记，那么你会感到悲伤。

修改

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

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

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

这样做：

{{1}}

Answer 5

在我看来，你的方法更好。 xml属性（如title =“blah”）用于定义特定标记的属性，但是当您进入更复杂的数据结构时，您希望根据对象进行更多思考，其中标记的属性实际上只是定义了额外的数据（如数据类型，格式等）。

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

例如“类型”之类的东西可能是该部分的适当属性（如果不确切知道你的建模，很难知道）但我会假设某些东西是合适的

Answer 6

当你公开承认自己不熟悉XML时，我会指出你W3 Schools的方向。至于你的问题，确实没有正确或错误的答案都是合理的。这取决于您自己的特殊偏好。

Answer 7

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

来自w3schools：

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

  ...

  使用属性的一些问题是：

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

属性难以阅读和维护。使用元素数据。使用属性来获取与数据无关的信息。

使用元素。

Answer 8

我个人设计XML方言的风格涉及属性和元素的混合，对元素很重要。我的一般经验法则是，每行不得超过80个字符（不包括前导空格），因此不应要求换行以便舒适地读取。

我将属性用于非常特定于它们所附加元素的简短项目，并且不可能被扩展为多个值。我倾向于制作布尔值，数值和枚举值属性。例如，对于图像参考元素，我将创建宽度，高度和格式属性。

我使用元素来获得更长的值（特别是那些可以是任意长度的元素），特别是那些可以延伸到更复杂结构的元素。例如，对于图像引用元素，我将为图像引用元素创建标题，标题，描述，URL和其他可能冗长的自由文本值子元素。

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

这是一个很好的XML吗？

8 个答案: