RE: Re: SVGT 1.2: Section 1.4, svgz

Eric and everyone - sorry, I hit the trigger too quickly on my previous
email. I am resending with fixes.

(This is the SVG Working Group response to
http://lists.w3.org/Archives/Public/www-svg/2005Dec/0308.html)

Eric,
Thanks for your suggestions. We are in general agreement with your
comments. 

We have decided to change the SVG spec in two places: add two sentences
to Appendix D.5.2 (note: D.4.3 talks about HTTP requirements on servers,
whereas D.5.2 talks about HTTP requirements on clients) and add a single
parenthetical 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
SVG, 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 data streams that
are downloaded from the server. Implementations must also support
progressive rendering of compressed data streams.
--------------------

We have decided to insert the following sentence into the above text
just before the last sentence: 
--------------------
When an SVG viewer retrieves compressed content (e.g., an .svgz file)
over HTTP, if the "Content-Encoding" and "Transfer-Encoding" response
headers are missing or specify a value that does not match the
compression method that has been applied to the content, then the SVG
viewer must not render the content and must treat the document as being
{{in error}{hyperlink to implnote.html#ErrorProcessing}}.
--------------------

Right now, section 1.4 (SVG MIME type, file name extension and Macintosh
file 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 letter). It is recommended that gzip-compressed SVG files stored
on Macintosh HFS file systems be given a file type of "svgz" (all
lowercase). 
--------------------

We have decided to add the following parenthetical sentence at the end
of section 1.4: 
--------------------
(See {{Conformance Criteria}{hyperlink to conform.html}} for more
information 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; thus, 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
.svgz, it's too late to change now. The one bit of history relative to
.svgz is that
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 were 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 support compression, .svgz allows content
to be delivered compressed. .svgz also means that authoring tools can
generate compressed content rather than delivering 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
these latest spec changes mandate how to handle errors but only add
clarification about when documents are in error.

Thanks for your comment. If you are unsatisfied with this response, then
please let us know within two weeks.

Jon Ferraiolo
Adobe Systems, Inc.
Member SVG WG

Received on Tuesday, 24 January 2006 23:58:51 UTC