W3C home > Mailing lists > Public > www-svg@w3.org > January 2006

Re: SVGT 1.2: Section 1.4, svgz

From: Jon Ferraiolo <jonf@adobe.com>
Date: Tue, 24 Jan 2006 14:24:10 -0800
Message-ID: <6ECA24BE410D994496A2AE995367C5C8642EF5@namail3.corp.adobe.com>
To: "Eric Seidel" <eseidel@apple.com>
Cc: <www-svg@w3.org>
(This is the SVG Working Group response to
Thanks for your suggestions. We are in general agreement with your
We have decided to change the SVG spec in two places: add two sentences
Appendix D.5.2 (note: D.4.3 talks about HTTP requirements on servers,
D.5.2 talks about HTTP requirements on clients) and add a single
sentence to 1.4.
Right now Appendix D.5.2 (Conforming SVG Viewers) contains the following
statements about gzip-encoded data streams:
SVG implementations must correctly support gzip-encoded [RFC1952] and
deflate-encoded [RFC1951] data streams, for any content type (including
script files, images). SVG implementations that support HTTP must
support these
encodings according to the HTTP 1.1 specification [RFC2616]; in
particular, the
client must specify with an "Accept-Encoding:" request header [
HTTP-ACCEPT-ENCODING] those encodings that it accepts, including at
minumum gzip
and deflate, and then decompress any gzip-encoded and deflate-encoded
streams that are downloaded from the server. Implementations must also
progressive rendering of compressed data streams.
We have decided to insert the following two sentences into the above
text just
before the last sentence: 
When an SVG viewer retrieves compressed SVG content (e.g., an .svgz
file) over
HTTP 1.1 or later, if the "Content-Encoding" response header is missing
specifies a value that does not match that matches the compression
method that
has been applied to the content, then the SVG viewer must not render the
and must treat the document as being {{in error}{hyperlink to
implnote.html#ErrorProcessing}}. SVG viewers must not render compressed
delivered over HTTP 1.0 since that protocol does not support appropriate
response headers to indicate that the content is compressed. 
Right now, section 1.4 (SVG MIME type, file name extension and Macintosh
type) contains the following content: 
It is recommended that SVG files have the extension ".svg" (all
lowercase) on
all platforms. It is recommended that gzip-compressed SVG files have the
extension ".svgz" (all lowercase) on all platforms.
It is recommended that SVG files stored on Macintosh HFS file systems be
given a
file type of "svg" (all lowercase, with a space character as the fourth
It is recommended that gzip-compressed SVG files stored on Macintosh HFS
systems be given a file type of "svgz" (all lowercase). 
We have decided to add the following parenthetical sentence at the end
section 1.4: 
(See {{Conformance Criteria}{hyperlink to conform.html}} for more
about gzip-compressed SVG files transmitted over HTTP.) 
Regarding how the .svgz extension is "odd", the .svgz extension has been
part of
the SVG specification since SVG 1.0 and was also part of SVG Tiny 1.1;
whether it is "odd" or not is more philosophical at this point. .svgz is
required in SVG Tiny 1.2 for backwards compatibility with SVG Tiny 1.1.
Regarding whether it would have been better to use .svg.gz instead of
it's too late to change now. The one bit of history relative to .svgz is
there was clear and strong community feedback when SVG 1.0 was developed
that there
had to be a compressed version of SVG or else SVG would be a non-starter
due to
file size issues. There were key constituencies in the SVG community who
very sensitive to file size several years ago (when broadband was not so

prevalent). Also, for protocols (such as file: and ftp:) where do not
compression, .svgz allows content to be delivered compressed. .svgz also
that authoring tools can generate compressed content rather than
uncompressed content and hoping that the server will maybe compress it
for you.
Regarding Jim Ley's comments in
http://lists.w3.org/Archives/Public/www-svg/2005Dec/0315.html about not
mandating particular error handling behavior, we do not believe that
latest spec changes mandate how to handle errors but only add
about when documents are in error.
Thanks for your comment. If you are unsatisfied with this response, then
let us know within two weeks.
Jon Ferraiolo
Adobe Systems, Inc.
Member SVG WG

Received on Tuesday, 24 January 2006 23:39:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:06 UTC