Re: SVGT 1.2: Section 1.4, svgz

(Sending on behalf of Jon Ferraiolo)

Hi Eric,
This email is the official Last Call response to your comment at:
   http://lists.w3.org/Archives/Public/www-svg/2005Dec/0308.html
which is repeated at the bottom of this email. Our response also refers
to Jim Ley's email at:
   http://lists.w3.org/Archives/Public/www-svg/2005Dec/0315.html
which is also repeated at the bottom.

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

We have decided to change the SVG spec in two places: add one sentence
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 and deflate-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 minimum 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 just before the last
sentence above: 
--------------------
When an SVG user agent receives compressed SVG content (e.g., a .svgz
file) as an entity over HTTP, if the "Content-Encoding" response header
is missing or specifies 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
filetype) contains the following words: 
--------------------
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 now to change.

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
SVG WG

---------------------------------

From: Eric Seidel <eseidel@apple.com <mailto:eseidel@apple.com?Subject=Re%3A%20Proposed%20response%20to%3A%20%7B%20Re%3A%20SVGT%201.2%3A%20Section%201.4%2C%20svgz%20%7D&In-Reply-To=%253C6ECA24BE410D994496A2AE995367C5C87266C8%40namail3.corp.adobe.com%253E&References=%253C6ECA24BE410D994496A2AE995367C5C87266C8%40namail3.corp.adobe.com%253E>>
Date: Wed, 28 Dec 2005 15:44:45 -0600
Message-Id: <C9291AEF-DD11-4286-A287-80DF73714388@apple.com <mailto:C9291AEF-DD11-4286-A287-80DF73714388@apple.com?Subject=Re%3A%20Proposed%20response%20to%3A%20%7B%20Re%3A%20SVGT%201.2%3A%20Section%201.4%2C%20svgz%20%7D&In-Reply-To=%253C6ECA24BE410D994496A2AE995367C5C87266C8%40namail3.corp.adobe.com%253E&References=%253C6ECA24BE410D994496A2AE995367C5C87266C8%40namail3.corp.adobe.com%253E>>
To: www-svg@w3.org <mailto:www-svg@w3.org?Subject=Re%3A%20Proposed%20response%20to%3A%20%7B%20Re%3A%20SVGT%201.2%3A%20Section%201.4%2C%20svgz%20%7D&In-Reply-To=%253C6ECA24BE410D994496A2AE995367C5C87266C8%40namail3.corp.adobe.com%253E&References=%253C6ECA24BE410D994496A2AE995367C5C87266C8%40namail3.corp.adobe.com%253E>


== This message seems to have died somewhere in transit, resending. ==

Greetings,

It is my recommendation that section 1.4 when talking about svgz  
should make reference to Appendix D.4.3 which informs the implementor  
that svgz content MUST be sent with the correct Content-Encoding  
headers.

In fact, even stronger, I would recommend that either Appendix D.4.3  
or Section 1.4 specifically state that sending content w/o the proper  
headers is in error, and should be ignored by the user agent.

FireFox and Safari implementors have already had issues in this  
regard while implementing svgz support for SVG 1.1.

Furthermore, I will state for consideration, that the "svgz" file  
type, in the local-file case is rather odd.  As its existence  
requires conforming xml user agents to include gzip detection and  
decompression ability.  This same requirement is not made by HTML or  
any other xml standard (that I am aware of).  Other xml file formats  
I have seen have used .foo.gz instead of .fooz as SVG does.  Neither  
FireFox nor Safari currently support local svgz files, however we  
both eventually plan to do so as it is required by the 1.1 spec.

Thanks,
Eric

-------------------

From: Jim Ley <jim@jibbering.com <mailto:jim@jibbering.com?Subject=Re%3A%20Proposed%20response%20to%3A%20%7B%20Re%3A%20SVGT%201.2%3A%20Section%201.4%2C%20svgz%20%7D&In-Reply-To=%253C6ECA24BE410D994496A2AE995367C5C87266C8%40namail3.corp.adobe.com%253E&References=%253C6ECA24BE410D994496A2AE995367C5C87266C8%40namail3.corp.adobe.com%253E>>
Date: Wed, 28 Dec 2005 22:03:59 -0000
To: www-svg@w3.org <mailto:www-svg@w3.org?Subject=Re%3A%20Proposed%20response%20to%3A%20%7B%20Re%3A%20SVGT%201.2%3A%20Section%201.4%2C%20svgz%20%7D&In-Reply-To=%253C6ECA24BE410D994496A2AE995367C5C87266C8%40namail3.corp.adobe.com%253E&References=%253C6ECA24BE410D994496A2AE995367C5C87266C8%40namail3.corp.adobe.com%253E>
Message-ID: <dov21q$rjp$1@sea.gmane.org <mailto:dov21q$rjp$1@sea.gmane.org?Subject=Re%3A%20Proposed%20response%20to%3A%20%7B%20Re%3A%20SVGT%201.2%3A%20Section%201.4%2C%20svgz%20%7D&In-Reply-To=%253C6ECA24BE410D994496A2AE995367C5C87266C8%40namail3.corp.adobe.com%253E&References=%253C6ECA24BE410D994496A2AE995367C5C87266C8%40namail3.corp.adobe.com%253E>>



"Eric Seidel" <eseidel@apple.com <mailto:eseidel@apple.com?Subject=Re%3A%20Proposed%20response%20to%3A%20%7B%20Re%3A%20SVGT%201.2%3A%20Section%201.4%2C%20svgz%20%7D&In-Reply-To=%253C6ECA24BE410D994496A2AE995367C5C87266C8%40namail3.corp.adobe.com%253E&References=%253C6ECA24BE410D994496A2AE995367C5C87266C8%40namail3.corp.adobe.com%253E>> wrote in message 
news:C9291AEF-DD11-4286-A287-80DF73714388@apple.com...
> In fact, even stronger, I would recommend that either Appendix D.4.3
or 
> Section 1.4 specifically state that sending content w/o the proper 
> headers is in error, and should be ignored by the user agent.

This is a bad idea, please do not do this, please stop defining error 
behaviour, just state the document is in error and it is up to the user 
agent what to do with that fact.

Authors will know in error documents will not necessarily be
interopable. 
It is not the job of a specification to define everything that should
happen 
with erroneous content.  If it's not conformant, it's not SVG, stop
forcing 
users to do a particular thing with something that isn't SVG.

Jim.

Received on Wednesday, 19 April 2006 05:33:48 UTC