W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2012

Re: SVGZ, was: Re: minutes, SVG WG Sydney 2012 F2F day 4

From: Erik Dahlstrom <ed@opera.com>
Date: Tue, 17 Jan 2012 10:18:17 +0100
To: "Charles Pritchard" <chuck@jumis.com>
Cc: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Message-ID: <op.v771grj2geuyw5@localhost.localdomain>
On Sat, 14 Jan 2012 19:58:31 +0100, Charles Pritchard <chuck@jumis.com>  

> Please clarify this discrepancy:
> ---
> Consider making svgz files just as valid and useful as svg files
> cm: the spec says it has to be xml
> cl: the summary is that systems that look at the mime type and the  
> content encoding
> ... systems that don't that (such as the file system), have to look at  
> the file extension or the first bytes of the file
> resolution: SVG2 will clarify that SVGZ files should be treated the same  
> as SVG
> Gzip-compressed svg in data URIs
> cl: it would need to be an update to the rfc that defines the data URI
> resolution: this is outside of our charter. out of scope for SVG2
> ---
> My best understanding is that the XML suffix ought to be dropped from  
> the SVG2 mime type, to allow for sniffing the first few bytes of an svg  
> stream.
> There would still be a +xml mode, which would require traditional XML  
> processing.
> So we would have: image/svg+xml, valid XML, requires transfer encoding  
> (gzip) to be defined elsewhere.
> And image/svg, not necessarily valid XML, may be gzip-compressed; the  
> first few bytes have to be examined.
> This reconciles the two issues reasonably well. As for data URI on  
> "image/svg+xml", there are mechanisms in the data uri format to pass  
> appropriate variables, they're just not in use.
> -Charles

Should that be interpreted as a request for SVG2 to define a non-XML  
parsing mode, together with a new mediatype?

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Tuesday, 17 January 2012 09:19:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:14 UTC