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: Cyril Concolato <cyril.concolato@enst.fr>
Date: Sun, 12 Oct 2008 10:55:36 +0200
Message-ID: <48F1BB88.9010204@enst.fr>
To: Alex Danilo <alex@abbra.com>
CC: public-svg-wg@w3.org

Hi Alex,

Indeed, in my eagerness to answer your comment, I read your email too quickly and did not look at the test. Now that I've looked at it, I agree with you.

Cyril

Alex Danilo a écrit :
> 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
> 
>> Cyril
>>
>> 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
>>>
>>>
>>
>> -- 
>> Cyril Concolato
>> Maître de Conférences/Associate Professor
>> Groupe Mutimedia/Multimedia Group
>> Département Traitement du Signal et Images
>> /Dept. Signal and Image Processing
>> Ecole Nationale Supérieure des Télécommunications
>> 46 rue Barrault
>> 75 013 Paris, France
>> http://tsi.enst.fr/~concolat 
>>
>>
>>
> 
> 


-- 
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Département Traitement du Signal et Images
/Dept. Signal and Image Processing
Ecole Nationale Supérieure des Télécommunications
46 rue Barrault
75 013 Paris, France
http://tsi.enst.fr/~concolat 
Received on Sunday, 12 October 2008 08:56:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 12 October 2008 08:56:27 GMT