- From: Nathan <nathan@webr3.org>
- Date: Mon, 31 Jan 2011 22:52:52 +0000
- To: Larry Masinter <masinter@adobe.com>
- CC: "www-tag@w3.org" <www-tag@w3.org>
Larry Masinter wrote: > I don't see how using a URI instead of media type name of the > form x/y (text/html or image/svg+xml or whatever) helps solve > any problem at all. > > How is the world any different if everyone uses > > http://media-type-registry.w3.org/text/html > > instead of > > text/html > > except that web protocols need to send more bytes around? Ideally they wouldn't, they'd use "text/html" as normal, and to find the related RFC/spec (rather than googling) they'd simply lookup http://media-type-registry.w3.org/text/html which would redirect through to the relevant specification. Similarly users with custom / vendor / experimental media types could simply use the full uri in the token instead, to say http://example.org/specs/opensearch. where: http://media-type-registry.w3.org/ is the registry http://media-type-registry.w3.org/text is the text tree http://media-type-registry.w3.org/text/html is a media type identifier that redirects to the spec when dereferenced. "text/html" is a valid media type token because when appended to the registry uri, it redirects rather than 404s (and because it's registered as per how things are now) That was the initial thought anyway.. not ideal for types like +xml though, and as Eric pointed out, it would (potentially) promote exponential increase in domain specific / app specific mediatypes rather than generality and reuse. Best, Nathan
Received on Monday, 31 January 2011 22:54:41 UTC