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