W3C home > Mailing lists > Public > www-svg@w3.org > December 2004

Re: SVG12: image/svg+xml gzip requirements

From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
Date: Wed, 08 Dec 2004 16:13:34 -0500
Message-ID: <41B76E7E.9080600@Kodak.com>
To: Ian Hickson <ian@hixie.ch>
CC: Bjoern Hoehrmann <derhoermi@gmx.net>, www-svg@w3.org, ietf-types@iana.org

Ian Hickson wrote:

> I would strongly recommend that specs disallow sniffing of any kind, 
> treating all metadata as authorative (and giving explicit priorities to 
> handle metadata contradictions).

    I guess the issue is what do you consider metadata?  I consider the
fact that a file starts with the magic number for a gzip stream a
very reliable piece of metadata (much more reliable than HTTP
headers - oh and much more reliable than searching a document in
an unknown encoding for 'html').

    So, in my view you would have a metadata contradiction.

> In certain rare cases where sniffing is 
> required due to missing metadata (as in the lack of byte order information 
> when no authorative default is stated), then the sniffing performed should 
> be well defined in order to allow all UAs to have exact interoperability.

    I would actually be _very_ happy to see the SVG spec define how
this should be done, and in fact I think the portion of the spec
originally quoted was doing this.  The problem is that for some
bizzare reason people don't seem to want to consider the file it's
self a good source of metadata about what the file contains.

    For freeform text files I can understand this but gzip is a binary
format it's structure is very rigid and if it is not a gzip
stream you will find out quite quickly, not to mention it
even includes a CRC of the uncompressed data, it is essentially
beyond reason to consider a case where a gzip stream uncompresses
successfully and it is not in fact a gzip stream.

    Now if what you are left with is an SVG document or not is
a much tricker proposition.
Received on Wednesday, 8 December 2004 21:13:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:04 UTC