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:37:15 +0100
Message-ID: <245311517.20041210043715@w3.org>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Thomas DeWeese <Thomas.DeWeese@Kodak.com>, www-svg@w3.org, ietf-types@iana.org

On Wednesday, December 8, 2004, 6:38:43 PM, Bjoern wrote:

>>   I might also point out 4.2 where the last paragraph says:
>>
>>     Representation providers SHOULD NOT in general specify the
>>     character encoding for XML data in protocol headers since the data
>>     is self-describing.
>>
>>   Which would seem to support not including the character encoding
>>in the SVG mime type.

Yes, exactly.

BH> It does not.

It does, too! :) You know, I was i a TAG meeting last week and checked
with the other folks exactly what it says and what the intent is and, I
have to say, it does, too.

BH> It says you should not use the charset parameter,

Right. It says don't use it. I have spent some considerable time
discussing with Martin Dürst at the end of last week, and we identified
a couple of cases (dumb transcoders that don't know any XML, and JSP
generators) where its easier to generate a charset to fix up problems
than it is to generate a correct xml encoding declaration. In all the
resst of the cases, havin ga correct encoding declaration is far
preferable.

It then becomes a discussion of what is easier to fix

a) improve the dumb transcoders (for example, if they don't know any XML
then treat all +xml types as binary) and the dumb JSP, or
b) make every implementation have to deal with a charset parameter that
should not be used.


BH> it
BH> does not say XML MIME Type registrations should define inconsistent
BH> processing rules for XML resources that use the charset parameter.

No, it says that if present the charset parameter should give the same
information as the xml encoding declaration. In other words, it
recommends the well implemented, consistent and interoperable path
(nontext/*+xml with no charset parameter and a correct encoding
declaration ) rather than the vague and inconsistently implemented path
(mutually inconsistent metadata with priority rules, and a requirement
to rewrite instances when saving to disk or to upgrade all disk
operating systems to store per-file MIME metadata).

-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group
Received on Friday, 10 December 2004 03:37:14 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:29 GMT