ISSUE-192: Should a broken link cause a mobileOK test to fail?

Should a broken link cause a mobileOK test to fail?

State:

CLOSED

Product:

mobileOK Basic tests

Raised by:

Kai Scheppe

Opened on:

2007-03-29

Description:

ACTION-460: Raise an issue on broken links and their effect on mobileOK pass or
fail

Hi,
I was asked to raise an issue on LC-1639
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mobileOK-basic10-tests-
20070130/1639?cid=1639
which, in its core, asks if you encounter a 4xx or 5xx error code should the
mobileOK test fail?

We have left the answer open because I asked if this is true for the primary
resource or secondary, tertiary etc.?
In other words, are we asking that all resources linked /*from*/ the page I am
checking are available?

The arguments which were brought up against my point of view were that it is our
intent make a better web and to ensure that the user obtains that which he is
requesting. As such an error code is unacceptable and cannot be part of a
mobileOK claim. Also, the Best Practice would not refer to secondary links.


I strongly oppose failing on 4xx or 5xx, simply because we cannot require the
author to be responsible for linked content that is not under his control, at
any given time.
I also strongly oppose because I think we have and must concentrate on the
requested resource and nothing else.
Finally, we are in fact referring to any link.




Here are my arguments:
----------------------
In checking section 3.11 and 2.3.7 (see text below), I see that we explicitly
state secondary links are in fact to be considered.
However, we do not define a stop.
This means once we access those secondary links, we need to consider its
secondary links again
-- we will in fact be checking the entire web.

Furthermore, the original best practice refers to clearly indicating in a link
what the user will find once following the link.
That is sensible and focusses on the resource that was requested, as I think is
correct to do.
Nowhere do we specifiy that content must be found at a secondary link.
While we /*wish*/ there to be content, the vagaries of the web will make this a
task nearly unfulfillable for the average author.




Suggestion:
-----------
My suggestions are that

- a mobileOK test only applies to the delivered resource and nothing else

- unless a sure mechanism can be found to group resources and make a claim for
that group, we must restrict the test one delivered resource

- we at the least make a clear statement as to how far mobileOK checks go as far
the link hierarchy is concerned.




Text of the test
-----------------
3.11 LINK_TARGET_FORMAT

This test examines resources linked in a variety of ways from the resource being
tested. Its intent is to examine resources that are not vital to the rendering
and parsing of the page. In particular, contrast with 2.3.6 Included Stylesheet
Resources, whose definition includes types of resources like stylesheets which
are vital.

For each linked resource, as defined in 2.3.7 Linked Resources:

Request the resource

If the HTTP response\'s Content-Type header\'s value is not one of the Internet
media types listed in the Accept header in 2.3.2 HTTP Request, warn

PASS


The referenced section
----------------------
2.3.7 Linked Resources

Linked resources are resources linked to from the resource being tested, but
which are not vital to rendering that resource. Examples include resources
linked via hyperlinks.

Linked resources are defined as those that are referenced by:

* the href attribute of a (anchor) elements, and whose URI begins with the
\"http\" or \"https\" scheme
* the action attribute of form elements whose method attribute is not
present or is present with value \"get\"
* the href attribute of link elements whose rel and rev attribute do not
contain \"stylesheet\", charset attribute is not present or is present with value
\"UTF-8\", type attribute is not present or is present with one of the Internet
media types listed in the Accept header in 2.3.2 HTTP Request, media attribute
is either not present or is present and contains value \"all\" or \"handheld\", and
whose URI begins with the \"http\" or \"https\" scheme and refers to a resource that
is not the same as the resource being tested

Related Actions Items:

No related actions

Related emails:

1. Re: 3.8 IMAGE_MAPS (mobileOK version 1z) (from achuter@technosite.es on 2007-05-10)
2. 2.3.5 Included Resources (mobileOK version 1z) (from achuter@technosite.es on 2007-05-10)
3. Re: 3.8 IMAGE_MAPS (mobileOK version 1z) (from achuter@technosite.es on 2007-05-10)
4. Re: Claims ... using content labels (mobileOK version 1z) (from achuter@technosite.es on 2007-05-10)
5. mobileOK version 1z (from jrabin@mtld.mobi on 2007-05-09)
6. mobileOK version 1y (from jo@linguafranca.org on 2007-05-08)
7. Minutes for 24 April f2f (from mike@w3.org on 2007-04-25)
8. RE: [agenda] Agenda for 12 April Call (from ANEC_W3CRep_Bruno@vonniman.com on 2007-04-12)
9. Regrets (from ignacio.marin@fundacionctic.org on 2007-04-12)
10. Regrets (from rcasar@ibys.net on 2007-04-12)
11. Minutes from 12/4/07 BPWG (from mdw@w3.org on 2007-04-12)
12. Current Status of LC Comments on mobileOK Basic 1.0 following draft 1x (from jrabin@mtld.mobi on 2007-04-11)
13. RE: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from k.scheppe@t-online.net on 2007-04-02)
14. RE: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from ANEC_W3CRep_Bruno@vonniman.com on 2007-04-02)
15. Re: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from andrea@trasatti.it on 2007-03-31)
16. RE: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from k.scheppe@t-online.net on 2007-03-30)
17. Re: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from andrea@trasatti.it on 2007-03-30)
18. RE: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from jrabin@mtld.mobi on 2007-03-30)
19. Re: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from andrea@trasatti.it on 2007-03-30)
20. RE: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from k.scheppe@t-online.net on 2007-03-30)
21. RE: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from jrabin@mtld.mobi on 2007-03-30)
22. RE: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from dom@w3.org on 2007-03-30)
23. RE: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from jrabin@mtld.mobi on 2007-03-30)
24. RE: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from jrabin@mtld.mobi on 2007-03-30)
25. Re: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from andrea@trasatti.it on 2007-03-30)
26. Re: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from srowen@google.com on 2007-03-30)
27. ISSUE-192: Should a broken link cause a mobileOK test to fail? (from dean+cgi@w3.org on 2007-03-29)
28. RE: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from jrabin@mtld.mobi on 2007-03-29)
29. Re: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from srowen@google.com on 2007-03-29)
30. RE: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from luca.passani@openwave.com on 2007-03-29)
31. Re: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from dom@w3.org on 2007-03-29)
32. RE: ISSUE-192: Should a broken link cause a mobileOK test to fail? (from jrabin@mtld.mobi on 2007-03-29)

Related notes:

Display change log