RE: mobileOK Checker and URIs that use the "file" scheme

Hi,

>... the questions are:
>1. can we directly update the mobileOK Checker Java library to include 
>such an option?
 > - Pro: that's useful
  >- Con: the library should be a reference implementation of the spec, 
>this is not defined in the spec
>2. do we need to publish a WG Note on off-line mobileOK testing?
 > - Pro: that would define things properly
  >- Con: does the group really want to publish another document?

Nacho, Miguel and I have been discussing this a bit. As it's is probably
that we are not going to attend the call today, here are our thoughts on
this:

We see that the first option would be nice to have but would imply
some form of clarification like the one proposed in the second option.
Obviously, a WG Note would be the best approach. We offer to help
developing the note, if there is a formal resolution on this.

One option would be to add a link in the current web site offering the
Checker service indicating that there is an additional offline version
supporting the W3C Note.

Our apologies for not being able to attend the call today,

Regards,
Abel.

-----Mensaje original-----
De: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] En
nombre de Francois Daoust
Enviado el: lunes, 16 de marzo de 2009 16:56
Para: Mobile Web Best Practices Working Group WG
Asunto: mobileOK Checker and URIs that use the "file" scheme

[Dan, Jo, do you think we could add this as an agenda item?]

Hi,

mobileOK tests can only be applied to URIs with the HTTP/HTTPS scheme, 
according to the standard:
  "mobileOK tests are only meaningful when the URI under test resolves 
to HTML content delivered over HTTP." [1]

Although some tests of the mobileOK Basic Tests 1.0 rec do not mean 
anything outside of the HTTP context, others are still useful when 
applied to local content (e.g. PAGE_TITLE, TABLES_NESTED). The "local" 
use case is not that stupid in the sense that it allows to run tests 
while a Web page is being edited, even before the page is published on 
the Web.

In an email to the public-mobileok-checker mailing-list [2], Yeliz 
mentioned that she was going to work on extending the library to support

the file scheme so that mobileOK checks could be combined with WCAG 
tests as part of a single tool (IIRC).

We exchanged ideas about the changes that would be required in the 
Checker library for that to happen, and ended up with a wonderful plan 
that involves, among other things, the creation of an additional test 
outcome "CANNOTTELL" (we currently have PASS, FAILED, WARN).

That's when Jo dropped in the discussion [4] to make the point that what

we were discussing was good but not mobileOK.

In particular, given the following points:
- file checking would stay an option set when running the Checker (i.e. 
the Checker would reject URIs with the file scheme by default)
- the CANNOTTELL outcome would never be returned when running the 
Checker in normal mode (i.e. nothing changes in the Checker by default)
- the report returned when a file is checked will never return a 
"mobileOK" status (i.e. the best outcome one could get would be "tests I

checked look fine, you now need to publish your content so that I can 
run the full set of tests")

... the questions are:

1. can we directly update the mobileOK Checker Java library to include 
such an option?
  - Pro: that's useful
  - Con: the library should be a reference implementation of the spec, 
this is not defined in the spec

2. do we need to publish a WG Note on off-line mobileOK testing?
  - Pro: that would define things properly
  - Con: does the group really want to publish another document?

We wanted to get the group's opinion on this.

Thanks,
Francois.


[1] http://www.w3.org/TR/mobileOK-basic10-tests/#testing_validity
[2] 
http://lists.w3.org/Archives/Public/public-mobileok-checker/2009Feb/0000
.html
[3] 
http://lists.w3.org/Archives/Public/public-mobileok-checker/2009Feb/0006
.html
[4] 
http://lists.w3.org/Archives/Public/public-mobileok-checker/2009Mar/0002
.html

Received on Tuesday, 17 March 2009 12:30:16 UTC