Question

1）假设当媒体类型名称设置为＆＃34; X/xml＆＃34;时，软件代理 SA < / strong>能够识别表示格式中包含的超媒体控件 RF

a）如果 SA 收到以下HTTP回复（其中包含 RF ），那么＆＃34; text＆＃34;部分媒体类型名称 text/xml通知 SA 它应将 RF 作为纯XML 进行处理（因此，它不应该尝试识别超媒体控件）？

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

b）但是，如果 SA 收到以下HTTP回复，则＆＃34; X＆＃34;部分在媒体类型名称 X/xml，通知 SA ，在处理 RF 时，它还应识别超媒体控件

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

2）如果我在 1）中的理解是正确的，那么我假设所有的值都在＆＃34; xml＆＃34;之前。（说＆＃34; X/vnd.Y＆＃34;在媒体类型名称X/vnd.Y+xml中）用于通知软件代理商哪个处理模型它应该与 xml文档一起使用？

修改

我提前道歉是因为这么冗长

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）


假设＆＃34; X＆＃34;是＆＃34;申请......＆＃34;

你能澄清一下你在这里要说的话吗？也许媒体类型名称是application/xml？

第3）


如果＆＃34; X＆＃34;不是＆＃34;申请＆＃34;但是其他一些类型，可能不安全   让您的代理人解析文档。

X不仅仅描述（根据处理模型）应该如何解释/解析资源表示？因此，只要代理人试图将{{1>} 媒体类型名称 X命名为X/xml我想要的任何内容（例如blahblah/xml），处理此表示（通过设置为Content-Type header的{{1}}通过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 section 3：

纯文本旨在“按原样”显示。 ...其他子类型将用于表单中的丰富文本，其中应用程序软件可以增强文本的外观，但是为了获得内容的一般概念，不得要求使用此类软件。

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

1b）假设“X”是“应用程序”然后是，您的代理可以自由地解析文档以进行超媒体控制，并使用它们来决定将来的操作。如果“X”不是“应用程序”而是其他类型，则代理可能无法安全地解析文档。

2）你基本上是对的。有关详情，请查看RFC 6839 section 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显然是超媒体媒体类型。

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

他们不做的是在APPLICATION级别表示语义。

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

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

通过使用通用媒体类型，客户端和应用程序可以根据应用程序的需要在表示上分层自己的语义。更高级别的应用程序语义通过外部文档而不是媒体类型进行通信。通过rels和链接的文档以及表示中指定值的含义。

附录：

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

如果您遵循“registerCar”rel，那么您返回的表格与注册汽车有关的可能性非常高，HTML没有发言权。但是有关“registerCar”rel的详细信息是在外部记录的。表示中可能存在标记，例如<title>Car Registration Form</title>，但也可以委托给文档。但是没有标准表明资源表示的语义必然能够传达使用它的语义。

如果你的表格上有姓名和地址，那么这个名字是谁？哪个地址？如果你做“GET / person / 1 / homeaddress”，那么说你得到他们的家庭住址是公平的。但有效载荷的内省并不一定能告诉你。这完全是一个背景问题。

对于文档相关的媒体类型，有些是，有些则没有。 Atom有一些，HTML没有。哈尔没有。 IANA有一个通用标准化rels列表，但它们与媒体类型无关。它们适用于HTML或HAL。他们是正交的。

如果你打算使用标准化的rels，那么你应该接近标准化的语义，从而利用它们带来的标准和广泛的知识。但最终您的应用程序如何处理不同的rels取决于您的应用程序。

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

2 个答案: