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

On Sat, 14 Jan 2012 19:58:31 +0100, Charles Pritchard <chuck@jumis.com>  
wrote:

> 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