新的和改进的澄清:当没有预先存在的DTD/Schema时,结构化数据的XML提要设计最佳实践

一个好的饲料

1) 一个模式,因为这样你可以通过编程检查它,并且你知道它什么时候被更改了,这样可以节省很多争论

2) 告诉你它什么时候停

3) 始终如一

5) 有一个测试服务,可以充分利用所有现有的提要功能

6) 具有用于砂箱开发的新功能服务

事实上,我只使用过提供1,有时提供2的提要,但我们可以做梦。

没有DTD/模式,在代码遇到问题之前,您无法知道提要是否有效。因此,对于我来说,模式非常重要,无论是作为XML使用者还是生产者。

即使是一个简单的模式也很有用,可以定义元素、元素出现的次数等。一个详细的模式,根据需要进行限制或枚举就更好了。当我拥有这些文件时,我可以最大限度地减少我生成的XML中的错误数量,或者我可以验证发送给我的整个文件,并在必要时将其视为不符合要求而拒绝。这只是一种简洁、标准的输入验证方法。

这是一个好问题,但我不知道它比schema good更进一步!架构错误。

I18N,尤其是数字格式和邮戳是一个巨大的问题。最佳实践当然是在文档中声明格式,最好默认为UTC时间。

我想我唯一能建议的另一个好做法是,消费需要交互的多个提要时,不要试图按照它们的条件来处理它们,相反,您需要做的第一件事是将它们反序列化为标准对象或将它们转换为标准的内部模式。

如果不了解您的实际需求,就很难对传输机制或样式提出建议。例如,如果您正在进行基于拉的联合,HTTP可以提供有助于缓存的功能。如果您正在执行基于推送或发布/订阅协议,如 XMPP could be used .

对于您的提要本身,我建议您遵守公共规范,例如 Atom (如果您愿意,也可以使用RSS变体)。Atom包含了您提到的一些项目,例如编码内容和日期格式(在大多数情况下使用UTC最简单,然后转换为用户的本地时间进行显示)。通过坚持标准格式,还可以使用支持该规范的提要解析器。

如果您使用的是XML,那么父/子关系(其中子对象只有一个父对象)可以很容易地建模为父/子元素。如果子元素有多个父元素,则可以使用引用和属性链接元素。

我目前的一个个人问题是没有时区信息的时间戳。如果你正在处理来自世界各地的提要,那么没有时区的时间毫无意义。

编辑: 和不包含编码属性的提要,或包含编码属性,但不尊重编码属性的提要!

我想 MediaRSS 是一个非常好的提要模式。我喜欢它是因为:

• 它足够灵活,可以包含几乎任何类型的内容。
• 它允许您定义提要中包含的媒体组(很有用,例如,当您有多个图像分辨率或多种格式时)。
• 它定义了几乎所有类型媒体所共有的基本元数据,但并不需要所有这些元数据。我没有遇到任何媒体,我想把它放进一个它不能代表的提要中。

有一件事我希望它不会是一个任意参数的标签,这些参数应该传递给给定媒体的播放器,但我认为这没有什么意义,因为feed不应该知道关于播放器的任何信息。但有时我只需要将参数传递给Flash播放器。

老实说,“最佳实践”并不是万能的,所以任何答案都只适用于正在解决的特定问题。

然而,根据我的经验,这里列出了一些通用的XML和协议设计元素。

• 尽可能避免FTP/SFTP,因为它具有可靠性,尤其是SFTP,它们不是通用的实现。此外,大多数防火墙都允许端口80,但FTP/SFTP可能会遇到阻塞的端口。
• 使用包含版本或日期的命名空间实现架构。例如 http://yourcompany.com/xml/myfeed/2009/03 . 它传递有关何时修改模式的信息,还指示版本号,这对客户端很有用。
• 如果您的订阅被公开,请考虑为您的数据实现各种RDF标签。然后,您的数据将成为语义网的一部分。