Re: SVGT 1.2: Section 1.4, svgz

This is satisfactory, thank you.

-eric

On Apr 18, 2006, at 10:33 PM, Andrew Shellshear wrote:

> (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 07:19:14 UTC