什么时候应该使用XML属性？何时应该使用XML元素？
例如
要么
foo bar
Ryan Taylor.. 38
在IBM的网站上有一篇题为" XML设计原则:何时使用元素与属性 "的文章.
虽然似乎没有很多严格的规则,但在帖子中提到了一些很好的指导方针.例如,其中一个建议是在数据不能针对空白空间进行规范化时使用元素,因为XML处理器可以规范化属性中的数据,从而修改原始文本.
当我开发各种XML结构时,我发现自己不时会引用这篇文章.希望这对其他人也有帮助.
编辑 - 从网站:
核心内容原则
如果您认为有问题的信息是XML中表达或传达的基本材料的一部分,请将其放在元素中.对于人类可读的文档,这通常意味着正在传达给读者的核心内容.对于面向机器的记录格式,这通常意味着直接来自问题域的数据.如果您认为信息是主要通信的外围或附带信息,或者纯粹是为了帮助应用程序处理主要通信,请使用属性.这避免了使用辅助材料使核心内容混乱.对于面向机器的记录格式,这通常意味着对来自问题域的主要数据的特定于应用程序的符号.
作为一个例子,我已经看到许多XML格式,通常是在企业中本土化的,其中文档标题被放置在属性中.我认为标题是文档传播的一个基本部分,它应该始终在元素内容中.另一方面,我经常看到内部产品标识符作为元素被抛出到产品的描述性记录中的情况.在某些情况下,属性更合适,因为特定的内部产品代码对于大多数读者或文档的处理者来说不是主要的兴趣,特别是当ID是非常长或不可思议的格式时.
您可能听说过元素中的原理数据,属性中的元数据.以上两段确实表达了相同的原则,但在更加刻意和不那么模糊的语言中.
结构化信息原理
如果信息以结构化形式表示,特别是如果结构可以是可扩展的,则使用元素.另一方面:如果信息表示为原子令牌,请使用属性.元素是用于在XML中表达结构的可扩展引擎.几乎所有的XML处理工具都是围绕这一事实设计的,如果您将结构化信息正确地分解为元素,您会发现您的处理工具可以补充您的设计,从而提高生产力和可维护性.属性用于表示元素中表示的信息的简单属性.如果您通过将结构化信息用于属性来对抗XML的基本体系结构,那么您可能会获得一些似是而非的简洁和便利,但您可能会支付维护成本.
日期是一个很好的例子:日期具有固定的结构,通常作为单个标记,因此它作为属性有意义(最好用ISO-8601表示).另一方面,代表个人姓名是我见过这个原则惊喜设计师的案例.我在属性中看到了很多名字,但我一直认为个人名字应该是元素内容.个人名称具有令人惊讶的可变结构(在某些文化中,您可以通过省略敬语或假设某些部分名称来引起混淆或冒犯).个人名称也很少是原子令牌.例如,有时您可能希望按姓氏搜索或排序,有时也可以按姓氏搜索或排序.我应该指出,将一个全名移植到单个元素的内容中就像将它放在一个属性中一样是有问题的.
在IBM的网站上有一篇题为" XML设计原则:何时使用元素与属性 "的文章.
虽然似乎没有很多严格的规则,但在帖子中提到了一些很好的指导方针.例如,其中一个建议是在数据不能针对空白空间进行规范化时使用元素,因为XML处理器可以规范化属性中的数据,从而修改原始文本.
当我开发各种XML结构时,我发现自己不时会引用这篇文章.希望这对其他人也有帮助.
编辑 - 从网站:
核心内容原则
如果您认为有问题的信息是XML中表达或传达的基本材料的一部分,请将其放在元素中.对于人类可读的文档,这通常意味着正在传达给读者的核心内容.对于面向机器的记录格式,这通常意味着直接来自问题域的数据.如果您认为信息是主要通信的外围或附带信息,或者纯粹是为了帮助应用程序处理主要通信,请使用属性.这避免了使用辅助材料使核心内容混乱.对于面向机器的记录格式,这通常意味着对来自问题域的主要数据的特定于应用程序的符号.
作为一个例子,我已经看到许多XML格式,通常是在企业中本土化的,其中文档标题被放置在属性中.我认为标题是文档传播的一个基本部分,它应该始终在元素内容中.另一方面,我经常看到内部产品标识符作为元素被抛出到产品的描述性记录中的情况.在某些情况下,属性更合适,因为特定的内部产品代码对于大多数读者或文档的处理者来说不是主要的兴趣,特别是当ID是非常长或不可思议的格式时.
您可能听说过元素中的原理数据,属性中的元数据.以上两段确实表达了相同的原则,但在更加刻意和不那么模糊的语言中.
结构化信息原理
如果信息以结构化形式表示,特别是如果结构可以是可扩展的,则使用元素.另一方面:如果信息表示为原子令牌,请使用属性.元素是用于在XML中表达结构的可扩展引擎.几乎所有的XML处理工具都是围绕这一事实设计的,如果您将结构化信息正确地分解为元素,您会发现您的处理工具可以补充您的设计,从而提高生产力和可维护性.属性用于表示元素中表示的信息的简单属性.如果您通过将结构化信息用于属性来对抗XML的基本体系结构,那么您可能会获得一些似是而非的简洁和便利,但您可能会支付维护成本.
日期是一个很好的例子:日期具有固定的结构,通常作为单个标记,因此它作为属性有意义(最好用ISO-8601表示).另一方面,代表个人姓名是我见过这个原则惊喜设计师的案例.我在属性中看到了很多名字,但我一直认为个人名字应该是元素内容.个人名称具有令人惊讶的可变结构(在某些文化中,您可以通过省略敬语或假设某些部分名称来引起混淆或冒犯).个人名称也很少是原子令牌.例如,有时您可能希望按姓氏搜索或排序,有时也可以按姓氏搜索或排序.我应该指出,将一个全名移植到单个元素的内容中就像将它放在一个属性中一样是有问题的.
更好的思考元素与属性参数之一来自英国GovTalk指南.这定义了用于与政府相关的XML交换的建模技术,但它有其自身的优点,值得考虑.
必须设计模式,以便元素是XML实例中信息内容的主要持有者.属性更适合保存辅助元数据 - 提供有关元素内容的更多信息的简单项.属性不得用于限定可能导致歧义的其他属性.
与元素不同,属性不能保存结构化数据.因此,优选元素作为信息内容的主要持有者.但是,允许使用属性来保存有关元素内容的元数据(例如,日期的格式,度量单位或值集的标识)可以使实例文档更简单,更易于理解.
出生日期可能会在消息中表示为:
1975-06-03
但是,可能需要更多信息,例如如何验证出生日期.这可以定义为一个属性,使消息中的元素看起来像:
1975-06-03
以下是不合适的:
1975-06-03
这里不清楚代码是否符合VerifiedBy或ValueSet属性.更合适的表现是:
View of Birth Certificate 1975-06-03
我个人喜欢使用简单的单值属性的属性.元素(显然)更适合复杂类型或重复值.
对于单值属性,属性可以在大多数API中实现更紧凑的XML和更简单的寻址.
这在很大程度上取决于偏好.我尽可能使用Elements进行数据分组和数据属性,因为我认为这比替代方案更紧凑.
比如我更喜欢......
...代替....
Rory
Becker
30
Travis
Illig
32
Scott
Hanselman
34
但是,如果我的数据不容易说20-30个字符或包含许多引号或其他需要转义的字符,那么我会说它是时候打破元素......可能还有CData块.
A programmer whose interested in all sorts of misc stuff. His Blog can be found at http://rorybecker.blogspot.com and he's on twitter as @RoryBecker
A cool guy for who has helped me out with all sorts of SVn information
Scott works for MS and has a great podcast available at http://www.hanselminutes.com
作为一般规则,我完全避免使用属性.是的,属性更紧凑,但元素更灵活,灵活性是使用XML等数据格式的最重要优势之一.今天的单一价值可以成为明天的价值清单.
此外,如果一切都是元素,您永远不必记住您是如何建模任何特定信息的.不使用属性意味着你可以少考虑一件事.
京公网安备 11010802040832号 | 京ICP备19059560号-6 