XML属性与XML元素

Question

在工作中,我们被要求创建XML文件以将数据传递给另一个离线应用程序,然后创建第二个XML文件以传回以更新我们的一些数据.在此过程中,我们一直在与其他应用程序的团队讨论XML文件的结构.

我提出的样本基本上是这样的:

<INVENTORY>
   <ITEM serialNumber="something" location="something" barcode="something">
      <TYPE modelNumber="something" vendor="something"/> 
   </ITEM>
</INVENTORY>

另一个团队表示,这不是行业标准,属性应仅用于元数据.他们建议:

<INVENTORY>
   <ITEM>
      <SERIALNUMBER>something</SERIALNUMBER>
      <LOCATION>something</LOCATION>
      <BARCODE>something</BARCODE>
      <TYPE>
         <MODELNUMBER>something</MODELNUMBER>
         <VENDOR>something</VENDOR>
      </TYPE>
   </ITEM>
</INVENTORY>

我建议第一个的原因是创建的文件的大小要小得多.在转移过程中,文件中将有大约80000个项目.实际上他们的建议比我建议的大三倍.我搜索了上面提到的神秘的"行业标准",但我能找到的最接近的是XML属性应该只用于元数据,但是辩论是关于什么是实际的元数据.

经过长时间的解释(对不起),您如何确定什么是元数据,在设计XML文档的结构时,您应该如何决定何时使用属性或元素？

Answer 1

我用这个经验法则:

1. 属性是自包含的东西,即颜色,ID,名称.
2. 元素具有或可能具有自己的属性或包含其他元素.

所以你的很近.我会做的事情如下:

编辑:根据以下反馈更新了原始示例.

  <ITEM serialNumber="something">
      <BARCODE encoding="Code39">something</BARCODE>
      <LOCATION>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

Answer 2

属性的一些问题是:

• 属性不能包含多个值(子元素可以)
• 属性不易扩展(用于将来的更改)
• 属性无法描述结构(子元素可以)
• 属性更难以通过程序代码进行操作
• 属性值不容易针对DTD进行测试

如果使用属性作为数据容器,则最终会得到难以阅读和维护的文档.尝试使用元素来描述数据.仅使用属性提供与数据无关的信息.

不要这样结束(这不是XML应该如何使用):

<note day="12" month="11" year="2002" 
      to="Tove" to2="John" from="Jani" heading="Reminder"  
      body="Don't forget me this weekend!"> 
</note>

资料来源:http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

Answer 3

"XML"代表"可扩展标记语言".标记语言意味着数据是文本,标记有关于结构或格式的元数据.

XHTML是按照预期方式使用的XML示例:

<p><span lang="es">El Jefe</span> insists that you
    <em class="urgent">MUST</em> complete your project by Friday.</p>

在这里,元素和属性之间的区别很明显.文本元素显示在浏览器中,属性是有关如何显示它们的说明(尽管有一些标签不能以这种方式工作).

当XML不是用作标记语言而是用作数据序列化语言时,会产生混淆,其中"数据"和"元数据"之间的区别更加模糊.因此,除了无法用属性表示的事物之外,元素和属性之间的选择或多或少是任意的(参见feenster的答案).

Answer 4

XML元素与XML属性

XML就是协议. 首先遵循社区或行业中任何现有的XML模式或已建立的约定.

如果您确实处于从头开始定义架构的情况,那么以下是一些应该通知元素与属性决策的一般注意事项:

<versus>
  <element attribute="Meta content">
    Content
  </element>
  <element attribute="Flat">
    <parent>
      <child>Hierarchical</child>
    </parent>
  </element>
  <element attribute="Unordered">
    <ol>
      <li>Has</li>
      <li>order</li>
    </ol>
  </element>
  <element attribute="Must copy to reuse">
    Can reference to re-use
  </element>
  <element attribute="For software">
    For humans
  </element>
  <element attribute="Extreme use leads to micro-parsing">
    Extreme use leads to document bloat
  </element>
  <element attribute="Unique names">
    Unique or non-unique names
  </element>
  <element attribute="SAX parse: read first">
    SAX parse: read later
  </element>
  <element attribute="DTD: default value">
    DTD: no default value
  </element>
</versus>

Answer 5

这可能取决于您的使用情况.用于表示从数据库生成的结构化数据的XML可以很好地与最终将字段值作为属性放置.

但是,用作消息传输的XML通常使用更多元素会更好.

例如,假设我们在答案中提出了这个XML: -

<INVENTORY>
   <ITEM serialNumber="something" barcode="something">
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
    </ITEM>
</INVENTORY>

现在我们要将ITEM元素发送到设备以打印条形码,但是可以选择编码类型.我们如何表示所需的编码类型？突然间,我们有点姗姗来迟地意识到条形码不是单一的自动值,而是可以通过打印时所需的编码进行限定.

   <ITEM serialNumber="something">
      <barcode encoding="Code39">something</barcode>
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

关键在于,除非您构建某种XSD或DTD以及命名空间以将结构固定在一块石头上,否则最好的选择就是打开您的选项.

当IMO XML可以在不破坏使用它的现有代码的情况下进行弯曲时,它是最有用的.

Answer 6

我在架构设计中使用以下关于属性与元素的指南:

• 使用元素来运行长文本(通常是string或normalizedString类型的文本)
• 如果元素有两个值(例如eventStartDate和eventEndDate)的分组,请不要使用属性.在前面的示例中,应该有一个"event"的新元素,它可能包含startDate和endDate属性.
• 营业日期,日期时间和数字(例如计数,金额和费率)应该是要素.
• 上次更新,到期等非业务时间元素应该是属性.
• 非业务数字(如哈希码和索引)应该是属性.*如果类型很复杂,请使用元素.
• 如果值是简单类型且不重复,请使用属性.
• xml:id和xml:lang必须是引用XML模式的属性
• 在技​​术上可行时首选属性.

属性的首选项是它提供以下内容:

• 唯一(属性不能多次出现)
• 订单没关系
• 上述属性是可继承的(这是"所有"内容模型在当前模式语言中不支持的内容)
• 奖励是它们不那么冗长并且占用更少的带宽,但这并不是优先考虑属性而非元素的理由.

我在技​​术上可以添加,因为有时候无法使用属性.例如,属性集选择.例如,使用当前模式语言无法使用(startDate和endDate)xor(startTS和endTS)

如果XML Schema开始允许限制或扩展"所有"内容模型,那么我可能会放弃它

Answer 7

这个问题没有普遍的答案(我参与了W3C规范的创建).XML可用于多种用途 - 类文本文档,数据和声明性代码是最常见的三种.我也经常使用它作为数据模型.这些应用程序的某些方面属性更常见,而其他属性则更自然.还有各种工具的功能,使其更容易或更难使用.

XHTML是属性具有自然用途的一个领域(例如,在class ='foo'中).属性没有顺序,这可能使某些人更容易开发工具.没有架构,OTOH属性更难键入.我还发现命名空间属性(foo:bar ="zork")在各种工具集中通常难以管理.但是看看一些W3C语言,看看常见的混合物.SVG,XSLT,XSD,MathML是众所周知语言的一些例子,它们都具有丰富的属性和元素.有些语言甚至允许多于一种方式来做,例如

<foo title="bar"/>;

要么

<foo>
  <title>bar</title>;
</foo>;

请注意,这些在语法上并不等同,并且需要在处理工具中明确支持)

我的建议是查看离您的应用程序最近的区域的常规做法,并考虑您可能希望应用的工具集.

最后确保将命名空间与属性区分开来.一些XML系统(例如Linq)将名称空间表示为API中的属性.国际海事组织这是丑陋的,可能令人困惑.

Answer 8

当有疑问时,KISS - 当你没有明确的理由使用属性时,为什么要混合属性和元素.如果您以后决定定义XSD,那么最终也会变得更干净.然后,如果您甚至后来决定从XSD生成类结构,那么也会更简单.

Answer 9

这两种存储对象属性的方法都是完全有效的。你应该远离务实的考虑。尝试回答以下问题：

1. 哪种表示会导致更快的数据解析\生成？

2. 哪种表示会导致更快的数据传输？

3. 可读性重要吗？

   ...

Answer 10

百万美元的问题!

首先,现在不要过于担心性能.你会惊讶于优化的xml解析器会快速浏览你的xml.更重要的是,您的未来设计是什么:随着XML的发展,您将如何保持松散的耦合和互操作性？

更具体地说,您可以使元素的内容模型更复杂,但扩展属性更难.

Answer 11

使用元素作为元数据的数据和属性(有关元素数据的数据).

如果元素在选择字符串中显示为谓词,则表明它应该是一个属性.同样,如果一个属性永远不会被用作谓词,那么它可能不是有用的元数据.

请记住,XML应该是机器可读的而不是人类可读的,对于大型文档,XML压缩得非常好.

Answer 12

其他人已经介绍了如何从元素中区分属性,但是从更一般的角度来看,将所有内容放在属性中是因为它使得生成的XML更小是错误的.

XML不是设计得紧凑,而是便携和人类可读.如果您想减少传输中的数据大小,请使用其他内容(例如Google的协议缓冲区).