我对媒体类型的理解正确吗？

Question

1)假设当媒体类型名称设置为"X/xml“时，软件代理SA能够识别包含在表示格式RF中的超媒体控件

a) (如果SA收到以下HTTP (其中包含RF )，那么媒体类型名称text/xml的"text“部分通知SAE 216，它应该将E 117RFE 218作为普通的XML处理(因此不应该尝试标识超媒体控件)？

HTTP/1.1 200 OK
       ...
Content-Type: text/xml
       ...
<order xmlns=″...″>
       ...
  <link rel=...″
        href=...″/>
</order>

b) (但如果SA收到以下HTTP，则媒体类型名称X/xml中的"X“部分通知SA，在处理RFE 229时，还应该识别超媒体控件。

HTTP/1.1 200 OK
       ...
Content-Type: X/xml
       ...
<order xmlns=″...″>
       ...
  <link rel=...″
        href=...″/>
</order>

2) (如果我在1)中的理解是正确的，那么我假设在"xml“之前的所有值(比如媒体类型名称X/vnd.Y+xml中的"X/vnd.Y”)都是用来通知软件代理，它应该在文档中使用哪种处理模型？

编辑：

我为自己的长篇大论事先道歉

1)

要澄清的是，XML没有超媒体控件。我想您指的是一种支持超媒体的XML格式，如Atom (application/atom+xml)。

我知道XML只是一种标记语言，因此没有超媒体控件。但我的理解是，如果我的自定义媒体类型MyMedia/xml将BeMyLink元素(定义在XML命名空间MySchemaNamespace中)标识为超媒体控件，那么当按照MyMedia/xml处理以下XML文档时(因此，当Content-Type标头设置为MyMedia/xml时)，BeMyLink元素被视为超媒体控件

<MyCreation xmlns="MySchemaNamespace">
      <BeMyLink rel="..."
                href="..."/>
</MyCreation >

2)

假设"X“是”申请.“

你能在这里澄清一下你的意思吗？也许那个媒体类型的名字是application/xml？

3)

如果"X“不是”应用程序“而是其他类型，则代理解析文档本身可能不安全。

X不是仅仅描述了(从处理模型的角度)应该如何解释/解析资源表示吗？因此，我不能将媒体类型名称X的一部分命名为X/xml (比如blahblah/xml )，只要试图处理该表示的代理(通过Content-Type header设置为blahblah/xml的HTTP响应接收到)知道(即知道如何根据blahblah/xml的指示处理该表示)的媒体类型blahblah/xml？

2.编辑

1)

这就是为什么应该使用标准媒体类型，而不是自定义媒体类型--因为最终，媒体类型本身并不是应用程序行为的驱动因素。

使用标准媒体类型并不是一个缺点，因为当代理接收到资源表示时，它不会仅仅通过检查媒体类型值是否在语义上理解表示而知道，而对于自定义媒体类型，代理只需查看媒体类型值是否知道资源表示的语义含义就可以判断。

2)

所以你应该使用标准媒体类型..。

那么，我还假设我们应该只使用标准(即那些在IANA上注册的) rel值。

3)

高级应用程序语义是通过外部文档传递的，而不是媒体类型。通过对rels和链接的文档化，以及表示中的命名值的含义。

也许我在吹毛求疵但是..。您说应该通过外部文档而不是媒体类型来传递更高级别的语义，但随后您注意到rel值的文档应该传递更高级别的语义。但是，在许多情况下，rel值不被认为是媒体类型的一部分(不总是，因为rel值也可以独立定义，例如在IANA中注册的那些值)。

谢谢

Answer 1

要澄清的是，XML没有超媒体控件。我想您所指的是一种支持超媒体的XML格式，比如Atom (application/atom+xml)。

1a)来自RFC 2046第3节

纯文本将显示为“原样”。..。其他类型用于丰富文本的形式，其中应用软件可增强文本的外观，但必须不需要这类软件才能获得内容的一般概念。

在您的示例中，接收到text/xml响应的软件代理可以选择增强文档的显示(可点击链接、语法突出显示等)。见附注1。

假设"X“是”应用程序“，那么是的，您的代理可以为超媒体控件自由解析文档，并使用它们来决定未来的操作。如果"X“不是”应用程序“而是其他类型，则代理解析文档本身可能不安全。

1. 你基本上是对的。有关更多信息，请访问RFC 6839第4.1节和RFC 3023。

对编辑的响应：

媒体类型采用type/[vnd.]subtype[+suffix]形式。由于"type“在这个上下文中有点模糊，我们通常称之为”顶级媒体类型“。宣布一种新的顶级媒体类型的理由很少，所以除非你绝对确定你需要它，否则就坚持使用标准:文本、图像、音频、视频和应用程序。[vnd.]是可选的供应商前缀，用于表示非标准的子类型。[+suffix]用于表示自定义子类型何时是现有标准子类型的专门化。

如果要定义自定义XML格式，请使用application/vnd.mymedia+xml。使用application表示文档将与程序一起使用，而不是人工显示。使用vnd.表示它是不标准的.使用+xml意味着，它是一个XML文档。mymedia是您的子类型的名称。

指出您所指的处理模型的是子类型，而不是顶级媒体类型。如果一个代理知道如何解析vnd.mymedia+xml，那么(理论上)如果它是application/vnd.mymedia+xml还是audio/vnd.mymedia+xml，那就无关紧要了，因为这两种类型都引用相同的文档格式。audio/vnd.mymedia+xml是否有任何意义是另一个问题。

注1:在实践中，您可能可以将text/xml视为application/xml，而不存在任何问题。但是，由于可能存在不可打印的数据，所以不能将application/xml视为text/xml。

Answer 2

你基本上走上正轨了。媒体类型表示表示该表示的处理模型。处理模型是对超媒体元素的“了解”。

因此，如前所述，text/xml不是超媒体类型，因为原始XML没有超媒体控件的概念。而XHTML显然是超媒体类型。

基于媒体类型的处理模型有效地表示表示的语法，以及媒体类型级别上的处理语义级别。

它们不做的是在应用程序级别表示语义。

这就是为什么您应该使用标准媒体类型，而不是自定义媒体类型--因为最终，媒体类型本身并不是应用程序行为的驱动因素。

考虑一下application/vnd.invoice+xml。这意味着(基于名称)该媒体表示某种类型的资源，例如发票。与简单的application/xhtml+xml相反。html格式显然没有“发票”语义，它甚至不隐含。

通过使用通用媒体类型，客户端和应用程序可以根据应用程序的需要对表示进行分层。高级应用程序语义是通过外部文档传递的，而不是媒体类型。通过对rels和链接的文档化，以及表示中的命名值的含义。

增编：

媒体类型是语法，而不是语义。例如，当您从请求中获得HTML表单时，表单是否用于提交地址信息？机场预订？税务信息？HTML媒体类型可以表示所有这些，但这些类型都与HTML媒体类型无关。

如果您遵循"registerCar“rel，您得到的表单与注册汽车有关的概率很高，HTML在其中没有发言权。但是关于"registerCar“rel的细节是外部记录的。表示中可能有标记，如<title>Car Registration Form</title>，但也有委托给文档的标记。但是，没有任何标准表明资源表示的语义一定能够传达使用它的语义。

如果你有一份填有姓名和地址的表格，那是谁的名字？哪个地址？如果你做了“获取/人/1/家庭地址”，那么公平地说你得到了他们的家庭地址。但对有效载荷的反省并不一定告诉你这一点。这都是背景问题。

至于那些文档化的媒体类型，有的没有，有的没有。Atom有一些，HTML没有。HAL没有。IANA有一个通用标准化rels的列表，但它们独立于媒体类型。它们将适用于HTML或HAL。它们是正交的。

如果您要使用标准化的rels，那么您应该严格遵循标准化的语义，从而利用它们所带来的标准和广泛的知识。但最终，应用程序如何处理不同的rels取决于应用程序。