blocks|key|337695|text|作者的观点是正确的(除了属性可能包含一个值列表)。问题是你是否关心他的观点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|337696|由你决定。|337697|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The author's points are correct (except that attributes may contain a list of values). The question is whether or not you care about his points. 

It's up to you.

blocks|key|337702|text|属性或元素的使用通常由您试图建模的数据决定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|337703|例如，如果某个实体是数据的PART，则建议将其设置为元素。例如，员工的姓名是员工数据的重要组成部分。|offset|length|style|BOLD|337704|现在，如果您想传达关于数据的METADATA+(提供有关数据的附加信息的内容)，但实际上不是数据的一部分，那么最好将其作为属性。例如，假设每个员工都有一个后端处理所需的GUID，那么将其设置为属性会更好(GUID并不能向查看xml的人传达真正有用的信息，但对于其他目的可能是必需的)|337705|没有这样的规则规定某些东西应该是属性或元素。|337706|完全没有必要避免使用costs..Sometimes属性，它们比元素更容易建模。这真的取决于您试图表示的数据。|337707|entityMap^0|0|D|4|0|E|8|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@$D|R|E|S|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@$D|U|E|V|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|O|$]]

Usage of attributes or elements is usually decided by the data you are trying to model.

For instance, if a certain entity is PART of the data, then it is advisable to make it an element. For example the name of the employee is an essential part of the employee data.

Now if you want to convey METADATA about data (something that provides additional information about the data) but is not really part of the data, then it is better to make it an attribute.
For instance, lets say each employee has a GUID needed for back end processing, then making it an attribute is better.(GUID is not something that conveys really useful information to someone looking at the xml, but might be necessary for other purposes)

There is no rule as such that says something should be an attribute or a element.

Its not necessary to AVOID attributes at all costs..Sometimes they are easier to model, than elements. It really depends on the data you are trying to represent.

blocks|key|3316225|text|这完全取决于XML的用途。当它主要是软件和机器之间的互操作时-例如Web服务，如果只是为了一致性(而且一些框架更喜欢这样做，例如WCF)，那么更容易实现全元素。如果它的目标是供人类使用-即主要由人们创建和/或读取-那么明智地使用属性可以大大提高可读性；XHTML就是一个很好的例子，XSLT和XML+Schema也是一个很好的例子。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3316226|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It all depends on what XML is used for. When it's mostly interop between software and machines - such as Web services it's easier to go all-elements if only for the sake of consistency (and also some frameworks prefer it that way, e.g. WCF). If it is targeted for human consumption - i.e. primarily created and/or read by people - then judicious use of attributes can improve readability quite a lot; XHTML is a reasonable example of that, and also XSLT and XML Schema.

blocks|key|3103451|text|我通常在属性是元数据的基础上工作--即关于数据的数据。我要避免的一件事是将列表放在属性中。例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3103452|attribute="1+2+3+7+20"|code-block|syntax|javascript|3103453|否则，您需要额外的解析级别来提取每个元素。如果XML提供了列表的结构和工具，那么为什么还要自己强加另一个。|3103454|您可能希望优先为属性编码的一种场景是通过SAX解析器提高处理速度。使用SAX解析器，您将获得一个包含元素名称和属性列表的元素回调。如果你使用了多个元素，那么你会得到多个回调(每个元素一个)。这是一个多大的负担/时间链，当然是有争议的，但也许值得考虑。|3103455|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I usually work on the basis that attributes are metadata - that is, data about the data. One thing I do avoid is putting lists in attributes. e.g. 

<pre><code>attribute="1 2 3 7 20"
</code></pre>

Otherwise you have an extra level of parsing to extract each element. If XML provides the structure and tools for lists, then why impose another yourself.

One scenario where you may want to code in preference for attributes is for processing speed via a SAX parser. Using a SAX parser you will get an element call back containing the element name and the list of attributes. If you had used multiple elements instead then you'll get multiple callbacks (one for each element). How much of a burden/timesink this is is up for debate of course, but perhaps worth considering.

blocks|key|340246|text|你可能会从语义的角度来看待这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|340247|如果数据与元素的联系更加紧密，那么它就是一个属性。|340248|即:一个元素的ID，我会把它作为元素的一个属性。|340249|但是，在解析文档时，属性可能比元素更令人头疼，这是事实。|340250|一切都取决于你，以及你如何设计你的模式。|340251|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

You could probably see the issue in a semantic way.

If the data is more tight linked with the element it would be an attribute. 

i.e: an ID of an element, i would put it as an attribute of the element.

But it's true that while parsing a document attributes could cause more headaches than elements.

All depends on you, and how you design your Schema.

blocks|key|340292|text|正是因为这种垃圾，你应该避免使用w3schools。如果有什么不同的话，那就是比他们关于JavaScript的可怕的事情还要糟糕。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|340293|作为一般规则，我建议内容-即预期将由最终用户使用的数据(无论是人类阅读，还是接收信息进行处理的机器)-最好包含在元素中。元数据-例如，与一段内容相关联的ID，但仅具有内部使用的价值，而不是向最终用户显示的价值-应该在属性中。|340294|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It's because of that kind of rubbish that you should avoid w3schools. If anything, that's even worse than the appalling stuff they have about JavaScript.

As a general rule, I would suggest that content - that is, data which are expected to be consumed by an end user (whether that be a human reading, or a machine receiving information for processing) - is best contained within an element. Metadata - for example an ID associated with a piece of content but only of value for internal use rather than for display to the end user - should be in an attribute.

blocks|key|3103616|text|重要的是，将内容放在属性中可以减少XML的冗长。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3103617|比较|3103618|<person+name="John"+age="23"+sex="m"/>|code-block|syntax|javascript|3103619|反对|3103620|<person>
++++<name>
++++++++John
++++</name>
++++<age>
++++++++<years>
++++++++++++23
++++++++</years>
++++</age>
++++<sex>
++++++++m
++++</sex>
</person>|3103621|是的，这有点偏颇和夸张，但你明白我的意思。|3103622|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

Not least important is that putting things in attributes makes for less verbose XML.

Compare

<pre><code>&lt;person name="John" age="23" sex="m"/&gt;
</code></pre>

Against

<pre><code>&lt;person&gt;
 &lt;name&gt;
 John
 &lt;/name&gt;
 &lt;age&gt;
 &lt;years&gt;
 23
 &lt;/years&gt;
 &lt;/age&gt;
 &lt;sex&gt;
 m
 &lt;/sex&gt;
&lt;/person&gt;
</code></pre>

Yes, that was a little biased and exaggerated, but you get the point

blocks|key|3316498|text|属性模型映射。元素上的一组属性直接同构到名称/值映射上，其中的值是文本或任何可序列化的值类型。例如，在C#中，任何Dictionary<string,+string>对象都可以表示为XML属性列表，反之亦然。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3316499|元素肯定不是这样的。虽然您总是可以将名称/值映射转换为一组元素，但情况并非如此，例如：|3316500|<map>
+++<key1>value</key1>
+++<key1>another+value</key1>
+++<key2>a+third+value</key2>
</map>|code-block|syntax|javascript|3316501|如果将其转换为映射，将会丢失两样东西:与key1关联的多个值，以及key1出现在key2之前的事实。|3316502|如果您查看用于以这样的格式更新信息的DOM代码，就会明白这一点的重要性。例如，写这段代码是很简单的：|3316503|foreach+(string+key+in+map.Keys)
{
+++mapElement.SetAttribute(key,+map[key]);
}|3316504|该代码简明扼要，毫不含糊。对比一下，比如说：|3316505|foreach+(string+key+in+map.Keys)
{
+++keyElement+=+mapElement.SelectSingleNode(key);
+++if+(keyElement+==+null)
+++{
++++++keyElement+=+mapElement.OwnerDocument.CreateElement(key);
++++++mapElement.AppendChild(keyElement);
+++}
+++keyElement.InnerText+=+value;
}|3316506|entityMap^0|1L|Q|0|0|0|K|4|X|4|14|4|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|11|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|12|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|13|8|@$9|14|A|15|B|C]|$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|O|3|P|5|6|7|1A|8|@]|D|@]|E|$]]|$1|Q|3|R|5|J|7|1B|8|@]|D|@]|E|$K|L]]|$1|S|3|T|5|6|7|1C|8|@]|D|@]|E|$]]|$1|U|3|V|5|J|7|1D|8|@]|D|@]|E|$K|L]]|$1|W|3|-4|5|6|7|1E|8|@]|D|@]|E|$]]]|X|$]]

Attributes model mapping. A set of attributes on an element isomorphizes directly onto a name/value map in which the values are text or any serializable value type. In C#, for instance, any <code>Dictionary&lt;string, string&gt;</code> object can be represented as an XML attribute list, and vice versa.

This is emphatically not the case with elements. While you can always transform a name/value map into a set of elements, the reverse is not the case, e.g.:

<pre><code>&lt;map&gt;
 &lt;key1&gt;value&lt;/key1&gt;
 &lt;key1&gt;another value&lt;/key1&gt;
 &lt;key2&gt;a third value&lt;/key2&gt;
&lt;/map&gt;
</code></pre>

If you transform this into a map, you'll lose two things: the multiple values associated with <code>key1</code>, and the fact that <code>key1</code> appears before <code>key2</code>.

The significance of this becomes a lot clearer if you look at DOM code that's used to update information in a format like this. For instance, it's trivial to write this:

<pre><code>foreach (string key in map.Keys)
{
 mapElement.SetAttribute(key, map[key]);
}
</code></pre>

That code is concise and unambiguous. Contrast it with, say:

<pre><code>foreach (string key in map.Keys)
{
 keyElement = mapElement.SelectSingleNode(key);
 if (keyElement == null)
 {
 keyElement = mapElement.OwnerDocument.CreateElement(key);
 mapElement.AppendChild(keyElement);
 }
 keyElement.InnerText = value;
}
</code></pre>

blocks|key|3103722|text|在决定XML格式时，还有一件事需要牢记:如果我没记错的话，"id“属性的值不能全是数字，它们必须满足XML中的名称规则。当然，这些值必须是唯一的。我有一个项目，它必须处理不满足这些要求的文件(尽管它们在其他方面是干净的XML+)，这使得处理这些文件更加复杂。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3103723|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Here's another thing to keep in mind when deciding on an XML format: If I recall correctly, the values of "id" attributes must not be all numeric, they must meet the rules for names in XML. And of course the values must be unique. I have a project that must process files that don't meet these requirements (although they are clean XML in other respects), which made processing the files more convoluted.

blocks|key|335477|text|您不能将CDATA放在属性中。根据我的经验，你迟早会想把单引号、双引号和/或整个XML文档放入一个“成员”中，如果它是一个属性，你就会咒骂那些使用属性而不是元素的人。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|335478|注意:我使用XML的经验主要是清理别人的。这些人似乎遵循着一句古老的格言："XML就像暴力，如果使用它不能解决您的问题，那么您使用得还不够多。“|335479|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You can't put a CDATA in an attribute. In my experience, sooner or later you are going to want to put single quotes, double quotes and/or entire XML documents into a "member", and if it's an attribute you're going to be cursing at the person who used attributes instead of elements.

Note: my experience with XML mainly involved cleaning up other peoples'. These people seemed to follow the old adage "XML is like violence. If using it hasn't solved your problem, then you haven't used enough."

blocks|key|3316743|text|我已经用谷歌搜索了确切的问题。首先，我阅读了这篇文章，http://www.ibm.com/developerworks/library/x-eleatt/index.html。然而，对于这样一个简单的问题来说，它感觉太长了。无论如何，我已经通读了所有关于这个话题的答案，但没有找到一个令人满意的总结。因此，我回到了后一篇文章。以下是摘要：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3316744|何时使用元素，何时使用属性表示信息？|style|BOLD|3316745|3316746|如果相关信息本身可以用元素进行标记，则将其放入一个元素中。|unordered-list-item|3316747|如果信息适合于属性形式，但最终可能是同一元素上具有相同名称的多个属性，则改用子元素。|3316748|如果信息必须是标准的类似DTD的属性类型，如ID、IDREF或ENTITY，则使用属性。|3316749|如果信息不应标准化为空白，则使用元素。(XML+processors+normalize+attributes|3316750|3316751|核心内容的原理|3316752|3316753|如果您认为有问题的信息是以XML语言表达或传达的基本材料的一部分，请将其放在元素中。如果您认为这些信息是主要通信的外围信息或附带信息，或者纯粹是为了帮助应用程序处理主要通信，请使用属性。|blockquote|3316754|3316755|3316756|结构化信息的原理|3316757|3316758|如果信息是以结构化形式表示的，尤其是如果结构是可扩展的，则使用元素。如果信息表示为原子令牌，则使用属性。|3316759|3316760|3316761|可读性的原则|3316762|3316763|如果信息是供人阅读和理解的，请使用elements。如果信息最容易被机器理解和消化，则使用属性。|3316764|3316765|3316766|元素/属性绑定的原理|3316767|3316768|如果您需要通过另一个属性修改元素的值，请使用元素。。。让一个属性修改另一个属性几乎总是一个糟糕的想法。|3316769|3316770|3316771|这是这篇文章中重要部分的简短总结。如果您希望查看每个案例的示例和完整描述，请参阅原始文章。|3316772|entityMap|0|LINK|mutability|MUTABLE|url|http://www.ibm.com/developerworks/library/x-eleatt/index.html|1|https://msdn.microsoft.com/en-us/library/ms256097(v=vs.110%2529.aspx)%2520in%2520ways%2520that%2520can%2520change%2520the%2520raw%2520text%2520of%2520the%2520attribute%2520value.^0|R|1P|0|0|0|I|0|0|0|0|0|K|Z|1|0|0|5|2|0|0|0|2L|0|0|0|0|5|6|2|0|0|0|1G|0|0|0|0|3|4|2|0|0|0|1C|0|0|0|0|7|8|2|0|0|0|1F|0|0|0|0|19|0^^$0|@$1|2|3|4|5|6|7|1X|8|@]|9|@$A|1Y|B|1Z|1|20]]|C|$]]|$1|D|3|E|5|6|7|21|8|@$A|22|B|23|F|G]]|9|@]|C|$]]|$1|H|3|-4|5|6|7|24|8|@]|9|@]|C|$]]|$1|I|3|J|5|K|7|25|8|@]|9|@]|C|$]]|$1|L|3|M|5|K|7|26|8|@]|9|@]|C|$]]|$1|N|3|O|5|K|7|27|8|@]|9|@]|C|$]]|$1|P|3|Q|5|K|7|28|8|@]|9|@$A|29|B|2A|1|2B]]|C|$]]|$1|R|3|-4|5|6|7|2C|8|@]|9|@]|C|$]]|$1|S|3|T|5|6|7|2D|8|@$A|2E|B|2F|F|G]]|9|@]|C|$]]|$1|U|3|-4|5|6|7|2G|8|@]|9|@]|C|$]]|$1|V|3|W|5|X|7|2H|8|@$A|2I|B|2J|F|G]]|9|@]|C|$]]|$1|Y|3|-4|5|6|7|2K|8|@]|9|@]|C|$]]|$1|Z|3|-4|5|6|7|2L|8|@]|9|@]|C|$]]|$1|10|3|11|5|6|7|2M|8|@$A|2N|B|2O|F|G]|$A|2P|B|2Q|F|G]]|9|@]|C|$]]|$1|12|3|-4|5|6|7|2R|8|@]|9|@]|C|$]]|$1|13|3|14|5|X|7|2S|8|@$A|2T|B|2U|F|G]]|9|@]|C|$]]|$1|15|3|-4|5|6|7|2V|8|@]|9|@]|C|$]]|$1|16|3|-4|5|6|7|2W|8|@]|9|@]|C|$]]|$1|17|3|18|5|6|7|2X|8|@$A|2Y|B|2Z|F|G]|$A|30|B|31|F|G]]|9|@]|C|$]]|$1|19|3|-4|5|6|7|32|8|@]|9|@]|C|$]]|$1|1A|3|1B|5|X|7|33|8|@$A|34|B|35|F|G]]|9|@]|C|$]]|$1|1C|3|-4|5|6|7|36|8|@]|9|@]|C|$]]|$1|1D|3|-4|5|6|7|37|8|@]|9|@]|C|$]]|$1|1E|3|1F|5|6|7|38|8|@$A|39|B|3A|F|G]|$A|3B|B|3C|F|G]]|9|@]|C|$]]|$1|1G|3|-4|5|6|7|3D|8|@]|9|@]|C|$]]|$1|1H|3|1I|5|X|7|3E|8|@$A|3F|B|3G|F|G]]|9|@]|C|$]]|$1|1J|3|-4|5|6|7|3H|8|@]|9|@]|C|$]]|$1|1K|3|-4|5|6|7|3I|8|@]|9|@]|C|$]]|$1|1L|3|1M|5|6|7|3J|8|@$A|3K|B|3L|F|G]]|9|@]|C|$]]|$1|1N|3|-4|5|6|7|3M|8|@]|9|@]|C|$]]]|1O|$1P|$5|1Q|1R|1S|C|$1T|1U]]|1V|$5|1Q|1R|1S|C|$1T|1W]]]]

I've used Google to search for the exact question. First I landed on this article, <a href="http://www.ibm.com/developerworks/library/x-eleatt/index.html" rel="noreferrer">http://www.ibm.com/developerworks/library/x-eleatt/index.html</a>. Though, it felt too long for a simple question as such. Anyhow, I've read through all the answers on this topic and didn't find a satisfactory summary. As such, I went back to the latter article. Here is a summary:

When do I use elements and when do I use attributes for presenting bits of information?

<ul>
<li>If the information in question could be itself marked up with elements, put it in an element.</li>
<li>If the information is suitable for attribute form, but could end up as multiple attributes of the same name on the same element, use child elements instead.</li>
<li>If the information is required to be in a standard DTD-like attribute type such as ID, IDREF, or ENTITY, use an attribute.</li>
<li>If the information should not be normalized for white space, use elements. (<a href="https://msdn.microsoft.com/en-us/library/ms256097(v=vs.110).aspx" rel="noreferrer">XML processors normalize attributes</a> in ways that can change the raw text of the attribute value.)</li>
</ul>

Principle of core content

<blockquote>
 If you consider the information in question to be part of the
 essential material that is being expressed or communicated in the XML,
 put it in an element. If you consider the information to be peripheral
 or incidental to the main communication, or purely intended to help
 applications process the main communication, use attributes.
</blockquote>

Principle of structured information

<blockquote>
 If the information is expressed in a structured form, especially if
 the structure may be extensible, use elements. If the information is
 expressed as an atomic token, use attributes.
</blockquote>

Principle of readability

<blockquote>
 If the information is intended to be read and understood by a person,
 use elements. If the information is most readily understood and
 digested by a machine, use attributes.
</blockquote>

Principle of element/attribute binding

<blockquote>
 Use an element if you need its value to be modified by another
 attribute. [..] it is almost always a terrible idea to have one attribute modify another.
</blockquote>

This is a short summary of the important bits from the article. If you wish to see examples and full description of every case, then refer to the original article.

blocks|key|338014|text|这是一个示例，其中属性是关于数据的数据。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|338015|数据库按其ID属性命名。|338016|数据库的"type“属性表示期望在数据库标记中找到的内容。|338017|++<databases>

++++++<database+id='human_resources'+type='mysql'>
++++++++<host>localhost</host>
++++++++<user>usrhr</user>
++++++++<pass>jobby</pass>
++++++++<name>consol_hr</name>
++++++</database>

++++++<database+id='products'+type='my_bespoke'>
++++++++<filename>/home/anthony/products.adb</filename>
++++++</database>

++</databases>|code-block|syntax|javascript|338018|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|O|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|P|8|@]|9|@]|A|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

This is an example where attributes are data about data.

Databases are named by their ID attribute.

The "type" attribute of the database denotes what is expected to be found inside the database tag.

<pre><code> &lt;databases&gt;

 &lt;database id='human_resources' type='mysql'&gt;
 &lt;host&gt;localhost&lt;/host&gt;
 &lt;user&gt;usrhr&lt;/user&gt;
 &lt;pass&gt;jobby&lt;/pass&gt;
 &lt;name&gt;consol_hr&lt;/name&gt;
 &lt;/database&gt;

 &lt;database id='products' type='my_bespoke'&gt;
 &lt;filename&gt;/home/anthony/products.adb&lt;/filename&gt;
 &lt;/database&gt;

 &lt;/databases&gt;
</code></pre>

blocks|key|340531|text|我的0.02五年后是完全相反的。让我解释一下。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|340532|当您对相似的数据和数据的属性进行分组时，|340533|使用元素。|ordered-list-item|340534|不要把元素用在所有东西上。|340535|如果数据重复(1对多)，如果数据从不重复，那么它可能是一个元素代码，并且只有在与其他东西相关时才有意义，它是一个属性。|340536|如果数据没有其他属性(即名称)，那么它是一个类似于attribute|340537|Group的元素，以支持集合解析(例如，/xml/character)|340538|Re-use+|340539|元素名称支持解析数据)|340540|340541|E217<|340542|>E217>，在元素名称中使用数字来表示位置。(例如，character1、character2)这种做法使得解析变得非常困难(参见#6，解析代码必须是/character1、/character2等，而不仅仅是/character。|340543|考虑另一种方式：|340544|首先考虑将所有数据分组为一个元素分组(+attribute.|340545|Logically+|unordered-list-item|340546|)。如果您了解数据，则很少需要将属性转换为元素。你可能已经知道当一个元素(集合，或重复的数据)是necessary|340547|Group元素在一起的时候，你会遇到这种情况，你需要扩展，添加新的元素/属性基于上面的逻辑结构logically|340548|When。添加一个新的子元素集合不会“破坏”您的设计，而且随着时间的推移会更容易阅读。|340549|340550|340551|例如，看一个简单的书籍和主要人物的集合，标题永远不会有“孩子”，它是一个简单的元素。每个角色都有自己的名字和年龄。|340552|++++<book+title='Hitchhiker&apos;s+Guide+to+the+Galaxy'+author='Douglas+Adams'>
++++++++<character+name='Zaphod+Beeblebrox'+age='100'/>
++++++++<character+name='Arthur+Dent'+age='42'/>
++++++++<character+name='Ford+Prefect'+age='182'/>
++++</book>

++++<book+title='On+the+Road'+author='Jack+Kerouac'>
++++++++<character+name='Dean+Moriarty'+age='30'/>
++++++++<character+name='Old+Bull+Lee'+age='42'/>
++++++++<character+name='Sal+Paradise'+age='42'/>
++++</book>|code-block|syntax|javascript|340553|你可以说一本书可以有多个作者。好的，只需通过添加新的author元素进行扩展(可以选择删除原始的@author)。当然，您已经破坏了原始的结构，但在实践中，它非常罕见，而且很容易解决。假设只有一个作者的原始XML的任何消费者都将不得不更改(他们可能会更改其DB，以便将作者从“book”表中的列移动到“author”表中)。|340554|<book+title='Hitchhiker&apos;s+Guide+to+the+Galaxy'>
++++<author+name='Douglas+Adams'/>
++++<author+name='Some+Other+Guy'/>
++++<character+name='Zaphod+Beeblebrox'+age='100'/>
++++<character+name='Arthur+Dent'+age='42'>
++++<character+name='Ford+Prefect'+age='182'/>
</book>|340555|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1R|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|1S|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|1T|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|1U|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|1V|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|1W|8|@]|9|@]|A|$]]|$1|Q|3|R|5|F|7|1X|8|@]|9|@]|A|$]]|$1|S|3|-4|5|F|7|1Y|8|@]|9|@]|A|$]]|$1|T|3|U|5|F|7|1Z|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|20|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|21|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|22|8|@]|9|@]|A|$]]|$1|11|3|12|5|13|7|23|8|@]|9|@]|A|$]]|$1|14|3|15|5|13|7|24|8|@]|9|@]|A|$]]|$1|16|3|17|5|13|7|25|8|@]|9|@]|A|$]]|$1|18|3|19|5|13|7|26|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|27|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|28|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|29|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|1G|7|2A|8|@]|9|@]|A|$1H|1I]]|$1|1J|3|1K|5|6|7|2B|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|1G|7|2C|8|@]|9|@]|A|$1H|1I]]|$1|1N|3|-4|5|6|7|2D|8|@]|9|@]|A|$]]]|1O|$]]

My 0.02 five years after the OP is the exact opposite. Let me explain. 

<ol>
<li>Use elements when you're grouping similar data, and attributes of
that data. </li>
<li>Don't use elements for everything. </li>
<li>If the data repeats (1 to many), it's probably an element</li>
<li>If the data never repeats, and only makes sense when correlated to
something else, it's an attribute.</li>
<li>If data doesn't have other attributes (i.e. a name), then it's an attribute</li>
<li>Group like elements together to support collection parsing (i.e. /xml/character)</li>
<li>Re-use similar element names to support parsing data </li>
<li>Never, ever, use numbers in element names to show position. (i.e. character1, character2) This practice makes it very hard to parse (see #6, parsing code must /character1, /character2, etc. not simply /character.</li>
</ol>

Considered another way:

<ul>
<li>Start by thinking of all your data as an attribute.</li>
<li>Logically group attributes into elements. If you know your data, you'll rarely need to convert attribute to an element. You probably already know when an element (collection, or repeated data) is necessary</li>
<li>Group elements together logically</li>
<li>When you run into the case the you need to expand, add new elements / attributes based on the logical structure an process above. Adding a new collection of child elements won't "break" your design, and will be easier to read over time.</li>
</ul>

For example, looking at a simple collection of books and major characters, the title won't ever have "children", it's a simple element. Every character has a name and age.

<pre><code> &lt;book title='Hitchhiker&amp;apos;s Guide to the Galaxy' author='Douglas Adams'&gt;
 &lt;character name='Zaphod Beeblebrox' age='100'/&gt;
 &lt;character name='Arthur Dent' age='42'/&gt;
 &lt;character name='Ford Prefect' age='182'/&gt;
 &lt;/book&gt;

 &lt;book title='On the Road' author='Jack Kerouac'&gt;
 &lt;character name='Dean Moriarty' age='30'/&gt;
 &lt;character name='Old Bull Lee' age='42'/&gt;
 &lt;character name='Sal Paradise' age='42'/&gt;
 &lt;/book&gt;
</code></pre>

You could argue that a book could have multiple authors. OK, just expand by adding new author elements (optionally remove the original @author). Sure, you've broken the original structure, but in practice it's pretty rare, and easy to work around. Any consumer of your original XML that assumed a single author will have to change anyway (they are likely changing their DB to move author from a column in the 'book' table to an 'author' table).

<pre><code>&lt;book title='Hitchhiker&amp;apos;s Guide to the Galaxy'&gt;
 &lt;author name='Douglas Adams'/&gt;
 &lt;author name='Some Other Guy'/&gt;
 &lt;character name='Zaphod Beeblebrox' age='100'/&gt;
 &lt;character name='Arthur Dent' age='42'&gt;
 &lt;character name='Ford Prefect' age='182'/&gt;
&lt;/book&gt;
</code></pre>

I am learning about <a href="http://www.w3schools.com/xml/xml_attributes.asp" rel="noreferrer">XML Attributes from W3Schools</a>.

The author mentions the following (emphasis mine):

<blockquote>
 <h2>XML Elements vs. Attributes</h2>

<pre><code>&lt;person sex="female"&gt;
 &lt;firstname&gt;Anna&lt;/firstname&gt;
 &lt;lastname&gt;Smith&lt;/lastname&gt;
&lt;/person&gt;
</code></pre>
 
 <hr>

<pre><code>&lt;person&gt;
 &lt;sex&gt;female&lt;/sex&gt;
 &lt;firstname&gt;Anna&lt;/firstname&gt;
 &lt;lastname&gt;Smith&lt;/lastname&gt;
&lt;/person&gt;
</code></pre>
 
 In the first example sex is an attribute. In the last, sex is an element. Both examples provide the same information.
 
 There are no rules about when to use attributes and when to use elements. Attributes are handy in HTML. In XML my advice is to avoid them. Use elements instead. 
 
 <h2>Avoid XML Attributes?</h2>
 
 Some of the problems with using attributes are:
 
 <ul>
 <li>attributes cannot contain multiple values (elements can)</li>
 <li>attributes cannot contain tree structures (elements can)</li>
 <li>attributes are not easily expandable (for future changes)</li>
 </ul>
 
 Attributes are difficult to read and maintain. Use elements for data. Use attributes for information that is not relevant to the data.
</blockquote>

So is the view of the author a famous one, or is this the best practice in XML?

Should Attributes in XML be avoided?

W3Schools also mentioned the following (emphasis mine): 

<blockquote>
 <h2>XML Attributes for Metadata</h2>
 
 Sometimes ID references are assigned to elements. These IDs can be used to identify XML elements in much the same way as the ID attribute in HTML. This example demonstrates this:

<pre><code>&lt;messages&gt;
 &lt;note id="501"&gt;
 &lt;to&gt;Tove&lt;/to&gt;
 &lt;from&gt;Jani&lt;/from&gt;
 &lt;heading&gt;Reminder&lt;/heading&gt;
 &lt;body&gt;Don't forget me this weekend!&lt;/body&gt;
 &lt;/note&gt;
 &lt;note id="502"&gt;
 &lt;to&gt;Jani&lt;/to&gt;
 &lt;from&gt;Tove&lt;/from&gt;
 &lt;heading&gt;Re: Reminder&lt;/heading&gt;
 &lt;body&gt;I will not&lt;/body&gt;
 &lt;/note&gt;
&lt;/messages&gt;
</code></pre>
 
 The ID above is just an identifier, to identify the different notes. It is not a part of the note itself.
 
 What I'm trying to say here is that metadata (data about data) should be stored as attributes, and that data itself should be stored as elements.
</blockquote>

Should I use Elements or Attributes in XML?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在学习。作者提到了以下内容(重点是我的)： XML元素与属性安娜·史密斯女安娜·史密斯在第一个例子中，性别是一个属性。最后，性是一个元素。这两个示例提供了相同的信息。没有关于何时使用属性和何时使用元素的规则。属性在HTML中很方便。我的建议是避免使用它们。改为使用元素。避免XML属性？使用属性的一些问题包括：元素属...

问我应该在XML中使用元素还是属性？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问我应该在XML中使用元素还是属性？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问我应该在XML中使用元素还是属性？
EN