Re: image/svg+xml

On Friday, August 30, 2002, 6:58:37 PM, Jim wrote:


JL> Hi,

JL> I have some issues with 1.1 mime-type section in
JL> http://www.w3.org/TR/SVG11/intro.html

JL> I believe 1.2 SVG MIME type to contain errors.

Thanks for your comments, Jim. I disagree on both of them:

JL> The section incorrectly states that the MIME type for svg is
JL> "image/svg+xml" quoting RFC 3023, a document which says that that
JL> mime-type SHOULD NOT be used.

No, the document correctly defines the media type type for SVG.

There is a chicken-and-egg situation in that the IETF requires a
stable specification to be referenced for media type registrations.
W3C terms a stable specification a Recommendation. To get to Rec is
has to pass the requirements for Candidate recommendation, whi ch
includes implementation experience and deployment. Thus, it needs
a MIME type.

Experience shows (I have been on the ietf-types list since around 1994
by the way) that the x- scheme is a complete failure and
counterproductive, so using a different temporary Media type before
registration is not good practice.

JL> I find the two documents to be incompatible, SVG 1.1 says use it, RFC
JL> 3023 says don't - RFC 3023 should hold weight.  Also it notes that
JL> registration is underway - RFC 2048 says "Proposed media types are not
JL> formally registered and must not be used"  So RFC's are clearly saying
JL> that we should not be using such mime-types, so I do not agree that the
JL> spec should tell us to.

Its your right to decide so, and feel free to use a different,
experimental type such as application/x-jims-svg, but you will then
not have interoperability and will not be in conformance with the SVG
specification.

JL> Furthermore (and this is actually the more important issue) RFC 3023
JL> defines the +xml suffix so as to allow generic processing, however SVG
JL> 1.1 says that the "image/svg+xml" mime-type is also the correct mime-type
JL> for gzipped SVG content - this is incompatible with generic processing of
JL> xml documents which do not expect gzipped content.

This is, I am afraid to say, completely incorrect. I suggest you study
the history of the application/gzip media type to see why this is a
bad idea (but see below).

JL> I would recommend solving these issues by either declaring a different
JL> mime-type for gzipped (without the +xml suffix) and non-compressed svg.

No, that would be a terrible idea and contrary to recommended
practice.

JL> Or remove gzipped svg from the specification and make it a requirement
JL> that viewers support content-encoding, which is a very well established
JL> and supported mechanism for delivering compressed content (why did SVG
JL> re-invent the wheel?),

Why do you assume that SVG reinvented the wheel? I suggest you read
the spec a little more carefully.

What you are suggesting here is not your own novel invention, but is
the correct consequence of supporting the HTTP 1.1 compression feature
as required by the SDVG spec. So yes, if you have media type foo/bar and
you compress it, then it should be served as media type foo/bar not as
some other media type. Compression and decompression happens out of
band - the XML parser does not know that the content was compressed
because the network transport deals with it. And as you correctly
point out, the way that HTTP signals that compression has been applied
is with a Content-encoding header.

JL> I understand it is already supported by more SVG
JL> User Agents than support gzipped content served as image/svg+xml .

I would like to see what evidence leads you to this assertion, and why
you think that what you are proposing is any different to what the SVG
spec already does.



-- 
 Chris                            mailto:chris@w3.org

Received on Friday, 30 August 2002 13:26:27 UTC