W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2008

Re: Problem with coords-viewattr-05-t.svg in Tiny 1.2 test suite

From: Doug Schepers <schepers@w3.org>
Date: Sun, 12 Oct 2008 12:24:14 -0400
Message-ID: <48F224AE.3030308@w3.org>
To: Alex Danilo <alex@abbra.com>
CC: cyril.concolato@telecom-paristech.fr, public-svg-wg@w3.org

Hi, Alex-

We'd discussed this several months ago, and agreed it needed to be
fixed, but I can't find who had the action.

In any case, WE just resolved (again) to fix it, and Anthony did so a
couple of days ago"

Sorry for the delay, and thanks for catching that.


Alex Danilo wrote (on 10/12/08 4:36 AM):
> Hi Cyril,
> --Original Message--:
>>Hi all,
>>It's been a while since I did not send email on this list. I'm trying to become a little bit more active. Let me start with my 2 cents on this issue.
>>The spec says that the type attribute is a hint. As a hint it can be ignored, right? Therefore sniffing is allowed, no? It may be a bad practice according to the TAG finding but it is not forbidden.
>>Additionally, the spec says "the server metadata is authoritative over the type attribute". So when loading a file from the system, without real client/server communication, one can consider that the OS is the server and that the file extension is some sort of metadata and therefore displaying the image.
> I fully concur with the intention of your comments, but please
> see below.
> Firstly, the 'type' in question is not an attribute, and therefore
> not necessarily a hint. It's part of the 'data:' URI field which
> is covered by a specific RFC. SVG doesn't control what the
> existing RFC says.
> The fact is that the content is inline, not fetched
> from a server, namely being from a 'data:' URI. So there
> is no type negotiation done, it's an inline part of the
> SVG document, thus no server metadata.
> Also, the error is quoting 'image/jpg' as the MIME type which
> is incorrect and the correct type being 'image/jpeg' as specified
> in RFCs which are more than a decade old.
> There is no file extension referenced as part of the test error.
> Thanks for the comments, but the content of the test should
> be correct.
> Also, as an aside, as far as sniffing goes - ASV sniffs all
> 'data:' URIs and does not need the 'type' at all. This is
> in violation of the BNF for the 'data:' URI as per its RFC.
> My complaint was about the correctness of the test only.
> Cheers,
> Alex
>>Alex Danilo a écrit :
>>> Hi group,
>>> 	At risk of sounding like a broken record, the test-fest shows failure
>>> for a couple of implementations and passes for most implementations for the test
>>> 'coords-viewattr-05-t.svg'.
>>> 	I know I've said it before, but since no-one seems to have paid
>>> attention: THE INTERNET MEDIA TYPE (a.k.a. MIME TYPE) IS WRONG. Will someone
>>> please listen this time, please...
>>> 	All the referenced 'data:' URIs have the media type of 'image/jpg'.
>>> The correct media type is 'image/jpeg'.
>>>                                    ^
>>> 	Media types aren't 3 letter file extensions. As such, all implementations
>>> marked as a pass should be marked as fail, for magically deducing the type from
>>> an incorrect media type - possibly sniffing content as ASV does, or whatever.
>>> 	The corrected test works fine in one failing implementation that
>>> I've checked.
>>> 	Can we please get this fixed? I'm sure this is the third time
>>> I've raised it over the years.
>>> Alex
Received on Sunday, 12 October 2008 16:32:32 UTC

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