Re: Encoding single-byte tests

On 01/09/2014 11:26, "Martin J. Dürst" wrote:
> On 2014/08/31 20:52, Richard Ishida wrote:
>> On 30/08/2014 11:20, "Martin J. Dürst" wrote:
>>> On the other hand, testing that the browser uses U+FFFD when the
>>> Encoding spec says so makes sense, and that's what I have done.
>>
>> Yes, I agree it makes sense, thereby testing the decode algorithm rather
>> than just the index file information. I will update my tests, assertions
>> and results and hope to republish by tomorrow.
>
> Great.
>
> Please note that while for this test, we have to include testing some
> part of the decoding algorithm, the reason why I was doing that wasn't
> so much to test the decoding algorithm itself (we are very far from
> doing anything coming close to a comprehensive test for that), but in
> fact the index file information, in particular the absence of a line for
> certain byte values.
>
> If we don't do this, we could have an empty index file (even if just by
> chance or by accident) and the tests would all be green but the test
> result would be completely misleading.

The tests and results have been updated to check what happens if there 
is no line for a pointer in the index file. According to the single-byte 
decoding algorithm, this should produce U+FFD. See the updated results at
http://www.w3.org/International/tests/repository/encoding/indexes/results-aliases

I have tried to indicate, where the pass is only partial, how many 
errors were due to U+FFF not being served, vs. how many were due to 
unexpected characters being served that are not those in the tables. I 
did that in the summary. For details, open the test in the relevant 
browser (by clicking on the link to the left of the row). See for example
http://www.w3.org/International/tests/repository/encoding/indexes/results-aliases#iso-8859-6

The main differences are for windows-1253 and windows-874 and 
Chrome/Safari/Opera, but also 6 more IE boxes turned orange.

RI

Received on Monday, 1 September 2014 12:21:10 UTC