mOK response proposal

Hi group,

At the bottom you can find my proposal for the response on our mOK previous comments.

Note that there is currently no response on comment #2 [1] as we have received clarification about the idempotent assumption [2] and as I think there is no doubt that you can't test post as currently defined as it's said at [3]:

"..forms with method get are permissible in documents under test, but _must not be checked_ in case posting caused unwanted side effects..."

So IMO, the only open issues with comment #2 are editorial staff that should be notified with the comments on the new draft:

- the GET vs. POST typo
- the location of the "POST out of scope" clarification [3] vs. [4].

Maybe we may comment on the suitability of getting POST out of the label.

I have also no response on comment #12 [5] as I'm not sure why the issue with external CSS has not been addressed. IMO external CSS are implicity excluded by omission in the document, and I think this is the group intention as they explicity say they're not addressing style regions at this stage. Do you mean they should be explicity excluded in the document? Please somebody elaborate.

I'm waiting for your opinion or proposals.

[1] - [http://www.w3.org/2002/09/wbs/32094/mOK_LCWD_response/results#xc2]
[2] - [http://lists.w3.org/Archives/Public/public-wai-ert/2007Jun/0063.html]
[3] - [http://www.w3.org/TR/mobileOK-basic10-tests/#visible_linked_resources]
[4] - [http://www.w3.org/TR/mobileOK-basic10-tests/#http_request]
[5] - [http://www.w3.org/2002/09/wbs/32094/mOK_LCWD_response/results#xc12]

Regards,
 CI.
 
--------------------------------------

Carlos Iglesias

CTIC Foundation
Science and Technology Park of Gijón
33203 - Gijón, Asturias, Spain 

phone: +34 984291212
fax: +34 984390612
email: carlos.iglesias@fundacionctic.org
URL: http://www.fundacionctic.org


############  DRAFT ############

Dear MWBP group,

The ERT WG [1] has looked again at your work on "mobileOK Basic Tests 1.0" (Draft 25 May 2007) [2], and we think some of the comments from our review on the previous draft [3] has not been completely addresed, so we would like further clarification on the following issues:

#1 ORIGINAL COMMENT:
Section "2.2 Testing outcomes"
The MWBP group have know made clear that warnings are _no_ test outcomes but it was also said that the group do not want to specify _which_ warning may be generated. In order for the tool developer to create a reasonable warning, it would help him to know at least the specific purpose why a warning has to be generated.

YOUR RESOLUTION:
The checker will provide a reference implementation of what the warning/error text should be for each warning or error, also linking back to appropriate reference material.

It's not clear what you mean with "linking back to appropriate reference material", what will be the appropiate reference material?, is the intention just to link back to the mOK or BP documents as is?. We think here the point is not to provide the text of a warning, but to ensure that it is clear what the potential problem assoiated with a warning is.


#2 ORIGINAL COMMENT:
Section "2.3.3 HTTP Response"
"If an HTTP request fails for any reason during a test (network-level error, DNS resolution error, non-HTTP response, or server returns an HTTP 4xx or 5xx status), the test outcome should be considered FAIL"
You can (and should) evaluate any content received from the server, error messages included as they're also content. When the server returns 4xx or 5xx the result of the test should not fail, because otherwise the website as a hole could never be Mobile OK compliant (e.g. you can always make a request that will produce an 404 and thus a fail)

YOUR RESOLUTION:
See http://lists.w3.org/Archives/Member/member-bpwg/2007Feb/0070.html

For 300 Multiple Choices [4] a page could be displayed, apparently depending on client's capabilities [5]. It's worth reviewing DDC capabilities to see if may be also neccessary carry out checks on 300 response codes.


#3 ORIGINAL COMMENT:
Section "3.10 MEASURES" reads: "If the value is non-zero and the unit is not "em", "ex" or "%", and the property is not a margin, border or padding box property (see also 3.20 SCROLLING (partial) ), FAIL"
There are other CSS properties where px values may be allowed as the background-position or the outline-width.

YOUR RESOLUTION:
We agree with the basic point but we will address it in the next phase of the Best Practices document instead.

Apparently there is some dependence of this test on the wording of the related BP, anyway we think this is an important issue that need to be addressed in any way before the Recommendation status because, as currently defined, this test could produce a fail outcome where it should be a pass. 


#4 ORIGINAL COMMENT:
Section "3.15 OBJECTS_OR_SCRIPT"
"If the value of the href attribute begins with the "javascript:" scheme, FAIL"
At least, href attributes with "#" (or any number of '#') value should also fail as it's a widely used value. A wider definition which discourages any misuse of href values in general would be desirable.

YOUR RESOLUTION:
We think that there are valid uses for allowing # as the href, such as a link to the top of the page.

Although being a valid URI, the behaviour of href="#" is not defined. Several user agents have the behavior describe above,  but we think this shouldn't be considered a good practice and the linking to the top of a page should be done using a real (not empty) anchor (fragment identifier). Having said that, we still think that at least href attributes with '#' (or any number of '#') should also fail.


[1] - [http://www.w3.org/WAI/ER/]
[2] - [http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/]
[3] - [http://lists.w3.org/Archives/Public/public-bpwg-comments/2007JanMar/0003.html]
[4] - [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1]
[5] - [http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12.2]


Regards,

Received on Friday, 22 June 2007 12:37:20 UTC