- From: Dave Hodder <dmh@dmh.org.uk>
- Date: Mon, 17 Jun 2002 20:22:04 +0000
- To: www-svg@w3.org
Hi, Given that no MIME media type for SVG has been defined through an RFC, here are my own thoughts on what such a registration could look like: MIME media type name: image MIME subtype name: svg+xml Required parameters: none Optional parameters: charset This parameter would have identical semantics to the charset parameter of the "application/xml" media type. profile This parameter would provide additional information for content negotiation purposes. (Is it SVG 1.0, SVG Tiny 3.1, etc.) Encoding considerations: (The same as application/xml.) Security considerations: (The same as application/xml.) The least obvious part, which I think needs the most thought, is how the theoretical 'profile' parameter could work. I can think of three potential schemes: 1) It could contain the URL of an official W3C SYSTEM identifier, in a similiar style to the profile attribute within RFC 3236 (the 'application/xhtml+xml' registration). For example, SVG Basic 1.1 could be: Accept: image/svg+xml; profile="http://www.w3.org/Graphics/SVG/1.1/DTD/svg-basic11.dtd" 2) As an alternative it could contain the value of the SVG document's baseProfile attribute. For example: Accept: image/svg+xml; profile="basic" 3) As example 2, but with an additional of a 'version' parameter: Accept: image/svg+xml; profile="basic"; version="1.1" (By having both 'profile' and 'version' parameters we are conveying as much information as example 1 above; example 2 falls short by not conveying this version information.) Do these ideas make sense? Which type of 'profile' parameter seems the most logical? I'd be interested to know whether the W3C has any intention of submitting an Internet-Draft for this media type in the near future; if not would anyone be unhappy about it happening independently of the W3C? ;o) Thanks Dave
Received on Monday, 17 June 2002 15:19:14 UTC