Re: Comments on mobileOK Basic 20070928 draft ( LC-1896 LC-1897 LC-1898 LC-1899 LC-1900 LC-1901 LC-1902 LC-1903 LC-1904 LC-1905 LC-1906 LC-1907 LC-1908 LC-1909)

 Dear Johannes Koch ,

The Mobile Web Best Practices Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the W3C mobileOK Basic
Tests 1.0 (Third Last Call) published on 28 Sep 2007. Thank you for having
taken the time to review the document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at
public-bpwg-comments@w3.org if you agree with it or not before 31 October
2007. In case of disagreement, you are requested to provide a specific
solution for or a path to a consensus with the Working Group. If such a
consensus cannot be achieved, you will be given the opportunity to raise a
formal objection which will then be reviewed by the Director during the
transition of this document to the next stage in the W3C Recommendation
Track.

Thanks,

For the Mobile Web Best Practices Working Group,
Michael(tm) Smith
W3C Staff Contact

 1. http://www.w3.org/mid/47160C24.9070306@fit.fraunhofer.de
 2. http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070928/


=====

Your comment on 2.4.2 HTTP Request:
> in Note: "have the have either the" -> "have either the"


Working Group Resolution (LC-1896):
Will fix this, thanks.

----

Your comment on 2.4.3 HTTP Response:
> * The algorithm does specify whether tests have to be carried out on 
> responses with 3xx, 401, 404, 407 and 5xx status codes. Is does _not_ 
> specify whether tests have to be carried out on responses with 1xx, 2xx
> 
> and 4xx (other than 401, 404 and 407).
> 
> It does specifiy whether the resource size/count totals have to be 
> updated for 3xx, 401, 407 status codes. Is does _not_ specify whether 
> the resource size/count totals have to be updated for 1xx, 2xx, 4xx 
> (other than 401 and 407) and 5xx status codes.


Working Group Resolution (LC-1897):
Yes, we will clarify that tests should proceed on 1xx (weird as that is)
or 2xx responses. The last lines of this section indicate that most 4xx
and 5xx responses will FAIL.

----

Your comment on 2.4.5 CSS Style:
> * Are values "all" and "handheld" meant case-insensitively?
> 
> * Are "stylesheet" and "alternate" meant case-insensitively?
> 
> * Is "UTF-8" meant case-insensitively?
> 


Working Group Resolution (LC-1898):
In both cases the relevant specification says case insensitive, so "yes"

----

Your comment on 2.4.6 Included Resources:
> * While section 2.4.7 lists element/attribute combinations (e.g. href 
> attribute of a element), section 2.4.6 does not provide attributes for
> 
> the elements:
>    * img elements (src attribute?)
>    * object elements (data attribute? some special param, e.g. value
>      attribute of param element with name="src"?
>    * link elements and xml-stylesheet processing instructions (href
>      (pseudo-) attribute?)
> 
> * Are values "all" and "handheld" meant case-insensitively?


Working Group Resolution (LC-1899):
Yes, I will add the attribute names as appropriate. Case-insensitive is
correct.

----

Your comment on 2.4.7 Linked Resources:
> * "GET" -> "get"
> Or is it meant case-insensitively?


Working Group Resolution (LC-1900):
The method is not case-sensitive, yes. I will clarify.

----

Your comment on 2.4.8 Validity:
> * " CSS
> 
>      A resource is considered a valid CSS resource if it conforms to
> the 
> grammar defined in [CSS], Appendix B (see note below).
> 
>      Note:
> 
>      The presence of at-rules, properties or values or combinations of
> 
> properties and values that are not specified in [CSS] does not 
> constitute a validity failure for CSS. See 3.21 STYLE_SHEETS_USE for 
> treatment of such values. In addition, the @media at-rule and the 
> presentation media qualifiers for the @import at-rule are taken into 
> account when evaluating CSS."
> 
> This is a contradiction: The CSS1 grammar does not allow at-rules other
> 
> than @import. How about the following wording (if that's what you
> mean)?
> 
> "A resource is considered a valid CSS resource if it conforms to the 
> grammar defined in [CSS], Appendix B, apart from possible uses of
> @media 
> at-rules with optional presentation media qualifiers."


Working Group Resolution (LC-1901):
Yes we will make a small clarification here.

----

Your comment on 3.2 CACHING:
> * "If the HTTP response contains neither an Expires nor Cache-Control 
> header"
> Is "nor Pragma" missing here?


Working Group Resolution (LC-1902):
Pragma is an HTTP 1.0 artifact, and for our purposes here we don't want to
consider this alone to be a sufficient communication of cacheability, so
yes we want to leave out Pragma.

----

Your comment on 3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP:
> * "In the following, an "html document" is a document that has "html" as
> 
> its root element."
> Are there any restrictions on the html element's namespace URI 
> (http://www.w3.org/1999/xhtml)?


Working Group Resolution (LC-1903):
No there are no restrictions -- the test is intended to proceed to test
any document that appears to be an HTML variant, and here that means any
document starting with <html> regardless of namespace.

----

Your comment on 3.5 DEFAULT_INPUT_MODE:
> * "For each input element with attribute type whose value is "text" or 
> "password""
> Does a missing type attribute in the markup assume the default value 
> "text" as per the document type definition?


Working Group Resolution (LC-1904):
Yes, probably a corner case but a good point.

----

Your comment on 3.6 EXTERNAL_RESOURCES:
> * "FAILures that occur in the course of making this assessment 
> contribute to the result of this test."
> Does this mean that a failure from the algorithm specified in 2.4.3 
> (http_response-x) creates another failure for 3.6
> (EXTERNAL_RESOURCES-1)?


Working Group Resolution (LC-1905):
Yes, it causes this test to fail -- this was the intent of this sentence,
right.

----

Your comment on 3.10 LINK_TARGET_FORMAT:
> * "If the Content-Type header value of the HTTP response is not 
> consistent with the Accept-Charset header in 2.4.2 HTTP Request, warn"
> What to do here if there is no charset parameter in the Content-Type
> header?


Working Group Resolution (LC-1906):
Yes, a missing charset parameter would be considered inconsistent too. We
will clarify.

----

Your comment on 3.15 OBJECTS_OR_SCRIPT:
> * "If the innermost nested object element content consists only of white
> 
> space (see 2.4.9 White Space), FAIL"
> "consists" -> "contains"?


Working Group Resolution (LC-1907):
OK.

----

Your comment on 3.21 STYLE_SHEETS_USE:
> * "If the CSS Style contains a property with a value that is 
> inappropriate to it, warn
> 
> If the CSS Style contains a property with a value that requires a unit
> 
> or a percentage:
> 
> If the unit (or percentage) is not present, warn
> 
> If the unit (or percentage) is inappropriate to the value, warn"
> 
> Does this only apply to properties specified in CSS1? Do newer 
> properties have to be ignored here?


Working Group Resolution (LC-1908):
The intention was that the test can only reasonably be expected to know
whether a property requires a unit if the property is known to the test,
and so far we have limited the test to CSS 1.

----

Your comment on 3.22 TABLES_ALTERNATIVES:
> * "If a table element exists," -> "For each table element"?
> Otherwise there would be at most one message for 
> "TABLES_ALTERNATIVES-1", "TABLES_LAYOUT-1", "TABLES_LAYOUT-2", 
> "TABLES_LAYOUT-3" and "TABLES_NESTED-1" per checked URI.


Working Group Resolution (LC-1909):
We'll change 3.23 and 3.24. I think the current wording is OK for 3.22
since that test check for existence of tables, period.

----

Received on Thursday, 25 October 2007 11:38:54 UTC