4 ms·

That is actually an interesting point. I can't pull up the HTTP spec or Dr. Fielding's dissertation right now, but what precisely is the mimetype supposed to si

That is actually an interesting point. I can't pull up the HTTP spec or Dr. Fielding's dissertation right now, but what precisely is the mimetype supposed to signify? It seems that that the encoding of the response (html/xml/json/etc) is being conflated with a content specification for the response. XML already allows you declare a schema for validation purposes. There have been a few attempts to standardize this on the JSON side, but that will never be a first-class citizen in JSON (nor do I think they should be). It appears to me, if you really care about the content of your resource, then you should use the schema facilities provided by your encoding, rather than imposing it universally on the architecture side, as the article implies. Historically, mimetypes (afaik) have never made any assumptions about the content of a resource, other than it adheres structurally to whatever the mimetype declares. Should be kept that way.

icebraining 15y ago
That limits the number of XML representations of any given resource to one, which can be a problem. In the context of a geographical object, XML might mean a KML file or an SVG image of the location, for example. There are plenty of IANA approved mimetypes which define a schema - in fact, HTML itself provides plenty of semantic information about the data.
- jallmann 15y ago
  You could narrow it down using standard mimetypes even if the alternate representation is a xml derivative. application/svg or whatever the mimetype for that is. The encoding for svg is well defined; SVG tags merely lend structure to the content. The same goes for HTML and any other markup. I'm undecided now though. It's a slippery slope with custom representations. With generic XML or JSON, you still need a priori knowledge of the content to parse the reprentation manually. Then the benefit of a nonstandard mimetype is simply to be absolutely explicit about your content. Whether that should be canonical, I'm not sure.
masklinn 15y ago
> what precisely is the mimetype supposed to signify? The meaning of the document you're returning. > XML already allows you declare a schema for validation purposes. But XML does not let you tag documents with arbitrary schemas. As far as I know, there is no way to include a RelaxNG or Schematron schema reference in an XML document in a standardized manner. Using specialized vendor mime types lets you provide this information: the mime type maps onto (among other things) the schema for the meta-type. > It appears to me, if you really care about the content of your resource, then you should use the schema facilities provided by your encoding There is nothing saying they can't go hand in hand. Indeed, it's quite the opposite: the vendor mime type you get maps directly to a corresponding schema for validation (the client generally should not validate what it gets, really, though it can). > Historically, mimetypes (afaik) have never made any assumptions about the content of a resource, other than it adheres structurally to whatever the mimetype declares. That's very much incorrect. See: application/xhtml+xml, application/svg+xml, model/x3d+vrml, application/soap+xml. And on the vendor-specific side of things, application/vnd.google-earth.kml+xml.

icebraining 15y ago

That limits the number of XML representations of any given resource to one, which can be a problem. In the context of a geographical object, XML might mean a KML file or an SVG image of the location, for example. There are plenty of IANA approved mimetypes which define a schema - in fact, HTML itself provides plenty of semantic information about the data.

jallmann 15y ago
You could narrow it down using standard mimetypes even if the alternate representation is a xml derivative. application/svg or whatever the mimetype for that is. The encoding for svg is well defined; SVG tags merely lend structure to the content. The same goes for HTML and any other markup. I'm undecided now though. It's a slippery slope with custom representations. With generic XML or JSON, you still need a priori knowledge of the content to parse the reprentation manually. Then the benefit of a nonstandard mimetype is simply to be absolutely explicit about your content. Whether that should be canonical, I'm not sure.

masklinn 15y ago

> what precisely is the mimetype supposed to signify? The meaning of the document you're returning. > XML already allows you declare a schema for validation purposes. But XML does not let you tag documents with arbitrary schemas. As far as I know, there is no way to include a RelaxNG or Schematron schema reference in an XML document in a standardized manner. Using specialized vendor mime types lets you provide this information: the mime type maps onto (among other things) the schema for the meta-type. > It appears to me, if you really care about the content of your resource, then you should use the schema facilities provided by your encoding There is nothing saying they can't go hand in hand. Indeed, it's quite the opposite: the vendor mime type you get maps directly to a corresponding schema for validation (the client generally should not validate what it gets, really, though it can). > Historically, mimetypes (afaik) have never made any assumptions about the content of a resource, other than it adheres structurally to whatever the mimetype declares. That's very much incorrect. See: application/xhtml+xml, application/svg+xml, model/x3d+vrml, application/soap+xml. And on the vendor-specific side of things, application/vnd.google-earth.kml+xml.