流式 XML Mime 类型？

Question

我正在构建一个发出流式 XML 的 Web 服务。 所以，输出看起来（在高层次上）是这样的：

<fragment1>
    <!-- ... -->
</fragment1>

<fragment2>
    <!-- ... -->
</fragment2>

...等等。 对于普通的 XML 文档，您可以使用以下任何一种不同的 MIME 类型：

• 应用程序/xml
• application/vnd.mycompany.com.description+xml（根据这个可爱的答案）
• 文本/xml

但是，这些 MIME 类型都假定响应只包含一个 XML 文档/片段。 就我而言，响应包含零个或多个片段。 出于这个原因，使用这些 MIME 类型之一似乎是错误的事情。 正确的处理程序会（正确地）将响应作为单个 XML 文档处理，并且要么 (a) 在到达第二个片段时 barf，要么 (b) 静默忽略从片段 2 开始的片段。

如果那是错误的事情，是这些 MIME 类型之一正确的事情：

1. application/octet-stream
2. application/vnd.mycompany.com.description.streaming+xml
3. application/vnd.mycompany.com.description+streaming-xml

还是我应该使用完全不同的？ 此外，如果数据格式上线后可以将 MIME 类型的相同“样式”应用于流式传输 JSON，那就太好了。

编辑：为了给这个问题更多的味道并提供一个我试图模拟的工作实现的例子，这个 API 是在Twitter 流 API之后建模的。

Answer 1

听起来除了您的流媒体要求之外，您的内容实际上是包含多个application/xml部分的多部分消息。 使用此布局application/json部分也可以混合在您的消息中。

如果您的个人 XML 片段是较大文档的一部分，请查看（有些陈旧和低调的） XML 片段交换 W3C 候选建议。 它定义了一种很好的语法来将片段主体与有关原始文档的上下文信息包装在一起。

Answer 2

根据数据中的语义关系及其结构，有多种选择。

第一个选项：如果您有一个（连续的）文件，可以通过将其包装在<elem> ... </elem>标签中轻松地将其转换为有效的 XML 文档，则它应该是application/xml-external-parsed-entity 。 这可以是从简单文本到注释、处理指令或复杂元素列表的任何内容。 但是，您不能插入 XML 声明（必须通过 MIME 定义字符集）或任何 DTD（因此，如果您依赖 DTD，则其含义必须由封闭文档提供，并且您也不能包含任何其他外部解析实体，除非您使用 XInclude）。

我发现这适用于可以描述为任意 XML 内容/片段的任何内容。 它主要用于通过 DTD 中的外部解析实体使用，但它本身也同样有效。 如果您的片段可能没有单个根节点，请使用此选项。 然而，我可以想到一个警告：如果流是无限的，客户端最终将不得不在某处终止它，并且由于没有指定外部边界，它可能会在元素的中间终止，根据到它的架构。

您也可以使用application/xml并自己编写开始标记，但是如果某些解析器配置为整体处理它，则它们可能会等待文档结束。 使用application/xml-external-parsed-entity ，最好的办法是将其解析为单个 XML 节点的流。

第二种选择：有多种类型的multipart类型。 这样，您可以包装单个 XML 文档（ application/xml或特定的）或片段（ application/xml-external-parsed-entity ）。 同样，内部类型的选择取决于各个消息是否可以被视为独立的 XML 文档（例如application/svg+xml用于“SVG 视频”）。

子类型的选择取决于整个序列的预期含义。 分组的单个独立文件流可以使用multipart/mixed （这是最通用的类​​型）。 如果 XML 数据以某种方式相互链接，您可以使用multipart/related并为各个片段分配标识符。 最后，如果只有消息的最后一部分代表资源的最新内容（以保存单个请求），则使用multipart/x-mixed-replace 。

---

举例说明：

• 如果响应是包含 XHTML 标记的文本流（例如从 Markdown 流转换而来），则它应该是单个application/xml-external-parsed-entity 。

• 如果片段是附件、经常从网站下载或用户上传的文件，则应该是multipart/mixed 。

• 如果片段是大型或不断增长的资源图中的节点（不仅仅是 XML），则应使用multipart/related 。

• 如果结果是一个短暂的信息，比如某个过程的当前状态或某个东西的连续测量，它应该是multipart/x-mixed-replace 。