W3C home > Mailing lists > Public > www-svg@w3.org > December 2004

Re: SVG12: image/svg+xml gzip requirements

From: Chris Lilley <chris@w3.org>
Date: Fri, 10 Dec 2004 04:46:29 +0100
Message-ID: <788213306.20041210044629@w3.org>
To: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, www-svg@w3.org, ietf-types@iana.org

On Wednesday, December 8, 2004, 7:18:50 PM, Thomas wrote:

TD>     Saying there can/should not be a charset parameter for
TD> image/svg+xml or if there is one it _must_ match the XML document's
TD> encoding is not the same as defining inconsistent processing rules, it
TD> is supporting the TAG finding.

Yes. Which is why its defined that way in the MIME registration.

TD>     What I don't get is why you think image/svg+xml can not possibly
TD> have anything different about it from text/xml.

Actually all text/* have sugfficient problems (mandatory fallback to
text/plain, suitability to be presented raw to the user as plain text,
mandatory fallback to us-ascii unless there is a charset parameter, een
for xml content with an encoding declaration) that text/*+xml is being
deprecated in RFC3023bis.

So we are left with image, application (heck, video, audio, model) /*+xml

TD>     I think that as long as someone _following_ the image/svg+xml
TD> mime-type registration does not break existing XML processors there
TD> is no legacy problem.

As shown by the past several years experience.

Relying on the xml encoding declaration allows content generation tools
to reliably state the character encoding used and to communicate this
reliably to the eventual parser without any special knowledge of a
particular server setup.

TD>  This would allow the registration to explicitly
TD> disallow charset and not break anything or require that it _always_
TD> match with undefined behavior if it doesn't.  If it specified the
TD> charset parameter was ignored that would be problematic.

Right, which is why it doesn't do that.

TD>     Does anyone think it really was a good idea to allow for a
TD> charset that differs from the content?

No, it was a really bad idea that snuck in with an attempt to make
text/*+xml work. It didn't work, and is being deprecated.

TD>  Or are we just propagating a
TD> bad decision on future generations?

Hopefully not.

 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group
Received on Friday, 10 December 2004 03:46:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:04 UTC