在工作中,我们被要求创建XML文件以将数据传递给另一个离线应用程序,然后创建第二个XML文件以传回以更新我们的一些数据.在此过程中,我们一直在与其他应用程序的团队讨论XML文件的结构.
我提出的样本基本上是这样的:
另一个团队表示,这不是行业标准,属性应仅用于元数据.他们建议:
something something something something something
我建议第一个的原因是创建的文件的大小要小得多.在转移过程中,文件中将有大约80000个项目.实际上他们的建议比我建议的大三倍.我搜索了上面提到的神秘的"行业标准",但我能找到的最接近的是XML属性应该只用于元数据,但是辩论是关于什么是实际的元数据.
经过长时间的解释(对不起),您如何确定什么是元数据,在设计XML文档的结构时,您应该如何决定何时使用属性或元素？
我用这个经验法则:
属性是自包含的东西,即颜色,ID,名称.
元素具有或可能具有自己的属性或包含其他元素.
所以你的很近.我会做的事情如下:
编辑:根据以下反馈更新了原始示例.
something XYX YYZ
属性的一些问题是:
属性不能包含多个值(子元素可以)
属性不易扩展(用于将来的更改)
属性无法描述结构(子元素可以)
属性更难以通过程序代码进行操作
属性值不容易针对DTD进行测试
如果使用属性作为数据容器,则最终会得到难以阅读和维护的文档.尝试使用元素来描述数据.仅使用属性提供与数据无关的信息.
不要这样结束(这不是XML应该如何使用):
资料来源:http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp
"XML"代表"可扩展标记语言".标记语言意味着数据是文本,标记有关于结构或格式的元数据.
XHTML是按照预期方式使用的XML示例:
El Jefe insists that you MUST complete your project by Friday.
在这里,元素和属性之间的区别很明显.文本元素显示在浏览器中,属性是有关如何显示它们的说明(尽管有一些标签不能以这种方式工作).
当XML不是用作标记语言而是用作数据序列化语言时,会产生混淆,其中"数据"和"元数据"之间的区别更加模糊.因此,除了无法用属性表示的事物之外,元素和属性之间的选择或多或少是任意的(参见feenster的答案).
XML就是协议. 首先遵循社区或行业中任何现有的XML模式或已建立的约定.
如果您确实处于从头开始定义架构的情况,那么以下是一些应该通知元素与属性决策的一般注意事项:
Content Hierarchical
- Has
- order
Can reference to re-use For humans Extreme use leads to document bloat Unique or non-unique names SAX parse: read later DTD: no default value
这可能取决于您的使用情况.用于表示从数据库生成的结构化数据的XML可以很好地与最终将字段值作为属性放置.
但是,用作消息传输的XML通常使用更多元素会更好.
例如,假设我们在答案中提出了这个XML: -
XYX YYZ
现在我们要将ITEM元素发送到设备以打印条形码,但是可以选择编码类型.我们如何表示所需的编码类型？突然间,我们有点姗姗来迟地意识到条形码不是单一的自动值,而是可以通过打印时所需的编码进行限定.
something XYX YYZ
关键在于,除非您构建某种XSD或DTD以及命名空间以将结构固定在一块石头上,否则最好的选择就是打开您的选项.
当IMO XML可以在不破坏使用它的现有代码的情况下进行弯曲时,它是最有用的.
我在架构设计中使用以下关于属性与元素的指南:
使用元素来运行长文本(通常是string或normalizedString类型的文本)
如果元素有两个值(例如eventStartDate和eventEndDate)的分组,请不要使用属性.在前面的示例中,应该有一个"event"的新元素,它可能包含startDate和endDate属性.
营业日期,日期时间和数字(例如计数,金额和费率)应该是要素.
上次更新,到期等非业务时间元素应该是属性.
非业务数字(如哈希码和索引)应该是属性.*如果类型很复杂,请使用元素.
如果值是简单类型且不重复,请使用属性.
xml:id和xml:lang必须是引用XML模式的属性
在技术上可行时首选属性.
属性的首选项是它提供以下内容:
唯一(属性不能多次出现)
订单没关系
上述属性是可继承的(这是"所有"内容模型在当前模式语言中不支持的内容)
奖励是它们不那么冗长并且占用更少的带宽,但这并不是优先考虑属性而非元素的理由.
我在技术上可以添加,因为有时候无法使用属性.例如,属性集选择.例如,使用当前模式语言无法使用(startDate和endDate)xor(startTS和endTS)
如果XML Schema开始允许限制或扩展"所有"内容模型,那么我可能会放弃它
这个问题没有普遍的答案(我参与了W3C规范的创建).XML可用于多种用途 - 类文本文档,数据和声明性代码是最常见的三种.我也经常使用它作为数据模型.这些应用程序的某些方面属性更常见,而其他属性则更自然.还有各种工具的功能,使其更容易或更难使用.
XHTML是属性具有自然用途的一个领域(例如,在class ='foo'中).属性没有顺序,这可能使某些人更容易开发工具.没有架构,OTOH属性更难键入.我还发现命名空间属性(foo:bar ="zork")在各种工具集中通常难以管理.但是看看一些W3C语言,看看常见的混合物.SVG,XSLT,XSD,MathML是众所周知语言的一些例子,它们都具有丰富的属性和元素.有些语言甚至允许多于一种方式来做,例如
;
要么
; bar ;
请注意,这些在语法上并不等同,并且需要在处理工具中明确支持)
我的建议是查看离您的应用程序最近的区域的常规做法,并考虑您可能希望应用的工具集.
最后确保将命名空间与属性区分开来.一些XML系统(例如Linq)将名称空间表示为API中的属性.国际海事组织这是丑陋的,可能令人困惑.
当有疑问时,KISS - 当你没有明确的理由使用属性时,为什么要混合属性和元素.如果您以后决定定义XSD,那么最终也会变得更干净.然后,如果您甚至后来决定从XSD生成类结构,那么也会更简单.
百万美元的问题!
首先,现在不要过于担心性能.你会惊讶于优化的xml解析器会快速浏览你的xml.更重要的是,您的未来设计是什么:随着XML的发展,您将如何保持松散的耦合和互操作性？
更具体地说,您可以使元素的内容模型更复杂,但扩展属性更难.
使用元素作为元数据的数据和属性(有关元素数据的数据).
如果元素在选择字符串中显示为谓词,则表明它应该是一个属性.同样,如果一个属性永远不会被用作谓词,那么它可能不是有用的元数据.
请记住,XML应该是机器可读的而不是人类可读的,对于大型文档,XML压缩得非常好.
其他人已经介绍了如何从元素中区分属性,但是从更一般的角度来看,将所有内容放在属性中是因为它使得生成的XML更小是错误的.
XML不是设计得紧凑,而是便携和人类可读.如果您想减少传输中的数据大小,请使用其他内容(例如Google的协议缓冲区).
京公网安备 11010802040832号 | 京ICP备19059560号-6 