使用原生js给元素设置属性_何时使用元素与属性

最新推荐文章于 2023-10-23 14:33:47 发布

cuyi7076

最新推荐文章于 2023-10-23 14:33:47 发布

阅读量812

点赞数

文章标签：大数据 python java 编程语言人工智能

原文链接：https://www.ibm.com/developerworks/xml/library/x-eleatt/index.html

版权

使用原生js给元素设置属性

SGML中DTD设计的几个经常思考的问题已经沿袭了XML分支。无论您使用哪种XML模式语言，您都可能会问自己：

什么时候使用元素，什么时候使用属性来显示信息？
我什么时候需要元素顺序，什么时候我可以允许任意顺序？
什么时候应该在类似元素的序列周围使用包装器元素？

根据我与XML用户的合作经验，第一个问题是迄今为止最常见的问题。在某些情况下，答案非常明确：

如果有问题的信息本身可以用元素标记，则将其放在元素中。
如果该信息适合于属性形式，但最终可能会成为同一元素上多个具有相同名称的属性，请改用子元素。
如果要求信息采用标准的类似DTD的属性类型，例如ID ， IDREF或ENTITY ，请使用属性。
如果不应将信息标准化为空白，请使用元素。 （XML处理器以可以更改属性值的原始文本的方式规范化属性。）

不幸的是，设计决策通常不属于此类整洁的类别。问题仍然是如何在灰色区域做出正确的选择。通常的答案是：没有一个答案是正确的，请使用您的最佳判断。但这对于尝试使用XML的人不是很有帮助。没错，即使专家也不一定总是同意在某些情况下应采取的措施，但这没有理由不提供在XML和属性之间进行选择的基本准则。

首先，我想对我已经听过但不推荐的两个准则发表评论。我听说只是把一切都变成要素。给出的原因包括从属性使事情复杂化到属性可能阻碍可扩展性。但是，如果您不使用属性，那么您将忽略XML功能的一个非常重要的方面，而使用某些带分隔符的文本格式可能会更好。

我也听说过，如果这是您希望在浏览器中显示的材料，请使用element content 。该指南的问题在于，它鼓励人们从表示的角度考虑XML内容设计，这是两个不能混为一谈的考虑因素。我在本文中提出了一个非常相似的指南，但是我是根据内容的意图而不是表示的方式来表达它。

在本文的其余部分中，我提供了一组在元素和属性之间进行选择时建议的准则。

推荐准则

我已将这些指南分为一组原则，我认为这些原则构成了元素和属性之间的整体选择。这些准则都不是绝对的。将它们用作经验法则，并在您的特定需求需要时随意违反规则。

核心内容原则

如果您认为有问题的信息是用XML表示或传达的基本材料的一部分，请将其放在一个元素中。 对于人类可读的文档，这通常意味着正在传达给读者的核心内容。对于面向机器的记录格式，这通常意味着直接来自问题域的数据。 如果您认为该信息是主要通信的附带或附带信息，或者纯粹是旨在帮助应用程序处理主要通信的信息，请使用属性。 这避免了用辅助材料弄乱核心内容。对于面向机器的记录格式，这通常意味着对来自问题域的主数据使用特定于应用程序的符号。

作为示例，我看到了许多XML格式，通常在企业中自行开发，将文档标题放在属性中。我认为标题是文档沟通的基础部分，因此标题应始终位于元素内容中。另一方面，我经常看到这样的情况：将内部产品标识符作为元素扔到产品的描述性记录中。在某些情况下，属性更合适，因为特定的内部产品代码对于文档的大多数阅读者或处理者而言并不是最重要的，尤其是当ID的格式非常长或难以理解时。

您可能已经听说过原理数据在元素中，元数据在attribute中 。上面的两段确实表达了相同的原理，但是用了更多的考虑和更少的模糊语言。

著名的例外

我一直很谨慎地指出，我的设计准则很灵活，您肯定会找到例外的理由。您还将发现有必要在不同原理之间取得平衡。在许多标准XML词汇表的示例中，做出了有意识的设计决策，这些决策与我在本文中发表的原则相矛盾。这是一个样本。

SVG向量路径在单个属性中表示为一系列以空格分隔的数字，这与结构化信息的原理相矛盾。做出此决定是因为SVG迫切需要简洁，但由于它会使SVG格式的处理复杂化而受到批评。
在属性中允许使用级联样式表（CSS）样式的许多格式（例如XHTML 1.0和XSL-FO）都允许您创建样式的复杂描述，混合多个方面和度量单位。这与结构化信息原理相矛盾。有趣的是，这不再是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修改了part 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设计原则。我还将在“ 思考XML”专栏中继续简要讨论XML设计的问题。

翻译自: https://www.ibm.com/developerworks/xml/library/x-eleatt/index.html