W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > January 2008

RE: Recent updates regarding pending bugs

From: Abel Rionda <abel.rionda@fundacionctic.org>
Date: Thu, 24 Jan 2008 16:46:52 +0100
Message-ID: <09700B613C4DD84FA9F2FEA52188281902DF5903@ayalga.fundacionctic.org>
To: "Dominique Hazael-Massieux" <dom@w3.org>
Cc: <public-mobileok-checker@w3.org>


>Hmm... Does this imply that no other tests will be run on the said page?

Not really. The tests will be launched despite triggering HTTP errors on the main document. But, be aware that in case of having a HTTP_RESPONSE_1 on the main document we will not have any kind of error page. (We see this case as the one in which launching tests would not make sense)

Regards,
Abel.

-----Mensaje original-----
De: Dominique Hazael-Massieux [mailto:dom@w3.org] 
Enviado el: jueves, 24 de enero de 2008 16:24
Para: Abel Rionda
CC: public-mobileok-checker@w3.org
Asunto: RE: Recent updates regarding pending bugs


Le jeudi 24 janvier 2008 à 16:04 +0100, Abel Rionda a écrit :

> 1.-Those that affect the rest of resources, except the main document.
>  The checking in this case is made inside each required test through a
> XSLT template. For example, in case of launching the test
> LINK_TARGET_FORMAT
>  against a linked resource with bad character encoding and HTTP not
> found error response, we would have the following test result:
> [...]

I think it shouldn't send the LINK_TARGET_FORMAT warning in addition to
the HTTP_RESPONSE one - i.e. I think the tests that depend on analyzing
the content of an HTTP requests shouldn't be run on the retrieved
resource if that retrieval triggered an HTTP error.


> 2.-Those that affect the main document.
> In this case we do not have a specific test for checking this, so we
> have defined a new test that join all HTTP_RESPONSE_* errors for the
> main document. 
>
> What do you think of this approach? If you agree that is the suitable
> one, we will commit the changes soon.

Hmm... Does this imply that no other tests will be run on the said page?
If so, this prevents someone to check that an error page is mobileOK,
which some people could find useful...

I think there should be some error message in the results output to make
it clear that the retrieved page triggered an HTTP error, but I'm not
sure I would make it stop any further processing (if that's what you're
suggesting).

Thanks for all the good work on this!

Dom
Received on Thursday, 24 January 2008 15:47:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 January 2008 15:47:02 GMT