Re: image/svg+xml

"Chris Lilley" <chris@w3.org> wrote in message
news:91104649328.20020830192611@w3.org...
>
> On Friday, August 30, 2002, 6:58:37 PM, Jim wrote:

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

Which document RFC 3023, or SVG 1.1 CR?

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

Certainly, we've discussed this before, however SVG 1.0 is a stable rec,
with good implementation experience, and I fail to see the difficulty in
using it as the basis for registering the mime-type.  Yet we've still not
even seen a draft, let alone anything else.

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

What I do, or don't do is irrelevent to me raising an issue against the
SVG 1.1 document, RFC 2048 is very clear on the fact, if that is no
longer the best current practice within the registration process, then it
should be superceded, until then it is certainly wrong to against
MUST's - or is it not?

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

I agree it would be a bad idea, it's certainly not a resolution I
would've liked, however I feel it's important when raising issues, that I
can where possible also raise potential solutions.

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

I can find no reference to content-encoding other than the fact that UA's
must send an appropriate Accept-Encoding header, I can find no mention of
a requirement that compressed svg documents be sent with the
corresponding content-encoding:gzip header.  Certainly Batik and ASV do
not require it.  Indeed it says "Implementations which support the HTTP
protocol must correctly support gzip encoded SVG data streams according
to the HTTP 1.1 specification"  - However it doesn't say that the
implementations must support HTTP 1.1.

The issue certainly appears to be an issue not about the intention of the
specification and the working group, but simply about the lack of
clarity.  This has led to all the compressed SVG I can find currently
deployed to be sent without the content-encoding header leading to the
very problem I've raised w.r.t. generic processors.

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

We are in agreement, I would like the spec to be clarified w.r.t. to
this.

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

See recent threads in mozilla's SVG newsgroup where Tobias Reif pointed
out the Mozilla failed to render gzip encoded content - as you have
clarified the spec, the bug is not in Mozilla it is in the vast majority
of currently deployed SVG.

> and why
> you think that what you are proposing is any different to what the SVG
> spec already does.

because the search
http://www.google.com/search?q=%22ontent-encoding%22+svg+inurl%3ATR+inurl
%3Asvg
returns no results, so I was led to believe (and in discussing this with
others, they agreed) that this was layered on top of HTTP 1.1 as purely
part of the SVG.

Jim.

Received on Friday, 30 August 2002 14:01:57 UTC