Comments on mobileOK Basic 20070928 draft

Hi BPWG,

here are my comments on the recent mobileOK Basic WD:


section 2.4.2

* in Note: "have the have either the" ->
"have either the"


section 2.4.3

* 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.


section 2.4.5

* Are values "all" and "handheld" meant
case-insensitively?

* Are "stylesheet" and "alternate" meant
case-insensitively?

* Is "UTF-8" meant case-insensitively?


section 2.4.6

* 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?


section 2.4.7

* "GET" -> "get"
Or is it meant case-insensitively?


section 2.4.8

* " 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."


section 3.2

* "If the HTTP response contains neither an Expires nor
Cache-Control 
header"
Is "nor Pragma" missing here?


section 3.4

* "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/x
html)?


section 3.5

* "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?


section 3.6

* "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)?


section 3.10

* "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?


section 3.15

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


section 3.21

* "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?


section 3.22/23/24

* "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.

-- 
Johannes Koch
BIKA Web Compliance Center - Fraunhofer FIT
Schloss Birlinghoven, D-53757 Sankt Augustin, Germany
Phone: +49-2241-142628    Fax: +49-2241-142065

 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-commentsw3.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.9070306fit.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/x
html)?


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.

----