- From: Jim Ley <jim@jibbering.com>
- Date: Tue, 18 Jun 2002 18:33:11 -0400
- To: <www-svg@w3.org>
624.8362.98.camel@sphinx> Subject: Re: The 'image/svg+xml' Media Type Date: Tue, 18 Jun 2002 23:34:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 "Braden McDaniel" <braden@lnk.com> > On Tue, 2002-06-18 at 08:40, Jim Ley wrote: > > [snip] > > > > JL> whatever objections may be found to image/svg+xml . > > > > > > Such as? > > > > I've not seen a draft... I have reservations about it being in the image > > space at all, it seems to fit better in application/* (are there not > > risks with non svg aware agents consider image/svg+xml to be binary data > > for example?) > > I don't think it's reasonable to assume "image" means the representation > isn't textual. The registry already seems to be populated with some that > are. I agree, however RFC 2046 doesn't, 4.2 Unrecognized subtypes of "image" should at a miniumum be treated as "application/octet-stream". So whilst I don't think that should prevent image/svg+xml, I still think it's something to consider (equally when svg is mixed with other XML namespaces xhtml/mathml etc. you would not be using image/* then - so why have image for this one arrangement? Dynamic SVG with text wrapping, xforms etc. I don't think image/svg+xml is "obvious". Jim.
Received on Tuesday, 18 June 2002 18:33:12 UTC