Draft message for the mOK last WD comments

Hi group,

The following is a draft for our comments to the last mOK WD.
I have tried to recover all the reviews and comments, but there was a bulk of comments, so please make sure that all the issues you have been raised are well-covered.

A few things that are currently omitted in a deliberate way:

- Comments related to CSS white spaces, as we are going first to ask about clarification of the need of verification of white spaces at CSS (Have a look to the #4 comment at [1])

- A couple of issues about measures and minimization (see rationale at [2]) although note that there are currently related issues in this draft 

Waiting for your suggestions.

[1] - [http://lists.w3.org/Archives/Public/public-wai-ert/2007Jun/0071.html]
[2] - [http://lists.w3.org/Archives/Public/public-wai-ert/2007Jun/0060.html]

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 has looked at your work on "mobileOK Basic Tests 1.0" (Draft 30 January 2007) [1], and the following feedback for your consideration resulted from our discussion, we hope it will be of help to you in progressing this work:

#1 COMMENT
* comment nature: [substantial]
* location: All the tests
* current wording: It looks like PASSES and FAILS are defined as "final states" that interrupt the algorithm (otherwise all the algorithms will always produce a PASS, as it's always the last instruction)
* suggested revision: Tests algorithms should be describe in a way that provide messages for every fail or warning
* rationale: If they not do so, then the algorithm would be useless for tracking reasons, you can use them to know if something PASS or FAIL, but not to know the details.

#2 COMMENT
* comment nature: [substantial]
* location: All the tests
* current wording: There is no reference to the applicability condition or prerequisites (when relevant) in the pseudo-code
* suggested revision: Include this applicability rules in the algorithms when relevant
* rationale: Some times could be not clear when to produce a N/A output vs. a Pass/Fail one. This is also a good practice for the shake of completeness in the algorithm

#3 COMMENT
* comment nature: [clarification]
* location: 2.3.2 HTTP Request
* current wording: Use the HTTP GET method when making requests.
* suggested revision: Clarify how to proceed while testing GET requests. E.g. use only default values
* rationale: It's quite clear now (see related #7 comment) what are the reasons to leave POST requests out, nevertheless there's no clear indication on how to proceed while testing GET requests.

#4 COMMENT
* comment nature: [clarification]
* location: 2.3.2 HTTP Request
* current wording: Use Implementations must support URIs with both http and https  scheme components.
* suggested revision: Clarify how to proceed with different URI schemes.
* rationale: It's not clear what should be done when you find a different URI scheme. Ignore it?

#5 COMMENT
* comment nature: [clarification]
* location: 2.3.3 HTTP Response
* current wording: If the HTTP status indicates redirection (status code 3xx):
  Do not carry out tests on the response
* suggested revision: It's not clear what to do with invalid location header values (URIs that are not absolute.
absoluteURI   = scheme ":" ( hier_part | opaque_part )
* rationale: Quite a lot of servers create
   Location: /foo.bar
  instead of
   Location: http://www.example.org/foo.bar

#5 COMMENT
* comment nature: [editorial]
* location: 2.3.5 CSS Style
* current wording: resources linked by xml-stylesheet  processing instructions
* suggested revision: resources linked by xml-stylesheet  processing instructions, as defined in 2.3.7 Included Style Sheet Resources"
* rationale: It make sense to reference the normative definition

#6 COMMENT
* comment nature: [clarification]
* location: 2.3.5, 2.3.6, 2.3.7
* current wording: At 2.3.5 is said that the CSS style must be assemble using @import rules among others, and at 2.3.6 this rules are also included in the definition of included resources, but at 2.3.7 there in no mention to @import while defining included style sheets that are taken into account when calculating the page size.
* suggested revision: Include @import rules into the page size calculation
* rationale: If CSS provided by @import rules is going to be analysed then it should also be taken into account while calculating the page size.

#7 COMMENT
* comment nature: [typo]
* location: 2.3.8
* current wording: Note that forms with method _get_ are permissible in documents under test, but must not be checked in case posting caused unwanted side effects such as the addition of unwanted records to a database.
* suggested revision: Note that forms with method _POST_ are permissible in documents under test, but must not be checked in case posting caused unwanted side effects such as the addition of unwanted records to a database.
*rationale: We think it's a typo as currently POST is the method that it's not been checked

#8 COMMENT
* comment nature: [editorial]
* location: 2.3.8
* current wording: Note that forms with method POST are permissible in documents under test, but must not be checked in case posting caused unwanted side effects such as the addition of unwanted records to a database.
* suggested revision: Add a similar note before 2.3.2 HTTP Request
*rationale: We think this clarification should also be done before as it's also quite relevant to correctly understand why at 2.3.2 the use of GET method is required.

#9 COMMENT
* comment nature: [clarification]
* location: 2.3.9 Validity
* current wording: "CSS > A resource is considered a valid CSS resource if it conforms to the grammar defined in [CSS], Appendix B."
* suggested revision: Include all the properties that are allowed in the definition of Valid CSS
* rationale: It's not clear what CSS properties are allowed as, apart from those in the CSS1 Recommendation, there are mentions at least to @media (3.21) and position (3.20).

#10 COMMENT
* comment nature: [clarification]
* location: 2.3.10 White space
* current wording: "Several tests refer to white space. White space has the same definition in this document as in XML. For XML 1.0 [XML10] it is defined in http://www.w3.org/TR/REC-xml/#sec-common-syn as being:
S ::= (#x20 | #x9 | #xD | #xA)+ i.e. the characters SP, TAB, CR and LF"
* suggested revision: Should   entities (#xA0) be considered?
* rationale: This entity is frequently used (and abused) and having a look at the related test (3.15, 3.17 and maybe 3.12) it makes even more sense

#11 COMMENT
* comment nature: [clarification]
* location: 3.2 CACHING
* current wording: In the following, note that HTTP headers should be used rather than meta elements with http-equiv attributes, which are commonly not taken into account by proxies. Where both a meta element and the corresponding header are found the value of the header must be used.
* suggested revision: Clarify what to do in the absence of HTTP headers, should meta elements be used?
* rationale:

#12 COMMENT
* comment nature: [typo]
* location: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
* current wording: application/xhtml+xml; charset=UTF-8"
* suggested revision: Remove '"'
* rationale:

#13 COMMENT
* comment nature: [clarification]
* location: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE and elsewhere where the message body is not involved (3.6, 3.10, 3.16)
* current wording: For each resource specified by 2.3.6 Included Resources:
   Request the resource
* suggested revision: Would a HEAD instead of GET request be sufficient?
* rationale: 

#14 COMMENT
* comment nature: [clarification]
* location: 3.4 CONTENT_FORMAT_SUPPORT  and VALID_MARKUP
* current wording: If the document is an HTML document
* suggested revision: What is "an HTML document" here? Which characteristics are to be checked?
* rationale: Is not clear if there's any algorithm to check whether something is an HTML document or not as it's not clear what you should look for in absence of an HTML document definition.

#15 COMMENT
* comment nature: [editorial]
* location: 3.6 EXTERNAL_RESOURCES
* current wording: "Note that if an HTTP request is unsuccessful while conducting this test, the result is FAIL"
* suggested revision: Include this condition in the general algorithm
* rationale: It's the only condition that affects to the result and it's out of the general algorithm, this way it could be easily leave out

#16 COMMENT
* comment nature: [clarification]
* location: 3.6 EXTERNAL_RESOURCES
* current wording: "Note that if an HTTP request is unsuccessful while conducting this test"
* suggested revision: Clarify what means unsuccessful here
* rationale:

#17 COMMENT
* comment nature: [typo]
* location: 3.6 EXTERNAL_RESOURCES
* current wording: Count the total number of unique included resources, as defined in 2.3.6 Included Resources
* suggested revision: Add '.'
* rationale:

#18 COMMENT
* comment nature: [clarification]
* location: 3.11 MEASURES
* current wording: "For each property in the CSS Style whose value is a numeric measure of length stated together with a unit
If the value is non-zero and the unit is not "em" or "ex"..."
* suggested revision: Why has been % left out? is it not considered an unit?
* rationale: As currently expressed it's not clear what to do with percentages

#19 COMMENT
* comment nature: [clarification]
* location: 3.11 MEASURES
* current wording: "For each property in the CSS Style whose value is a numeric measure of length stated together with a unit
If the value is non-zero and the unit is not "em" or "ex"..."
* suggested revision: The current wording could give the impression that numeric measures without units are allowed, which in general is not a good idea with some exceptions.
* rationale: Although this issue could be already covered by CSS validation, redundancy could be helpfull for the shake of
completeness in this test as "mobileOK tests are intentionally expressed in an independent way"

#20 COMMENT
* comment nature: [editorial]
* location: 3.12 MINIMIZE 3.15 OBJECTS_OR_SCRIPT 3.17 PAGE_TITLE
* current wording: "white space"
* suggested revision: Link to the "normative" definition of white space at 2.3.10 White Space
* rationale: Once you have a "normative" definition it make sense to link to it as it's been done with "Validity"

#21 COMMENT
* comment nature: [typo]
* location: 3.13 NO_FRAMES
* current wording: "If the document contains a frame, frameset or iframe element or object element..."
* suggested revision: "If the document contains a frame, frameset or iframe element or _an_ object element..."
* rationale: Apparently there is a missing "an"

#22 COMMENT
* comment nature: [clarification]
* location: 3.16 PAGE_SIZE_LIMIT
* current wording: If the size of the document's markup exceeds 10 kilobytes
* suggested revision: Does "size of the document's markup" mean "the markup document's length"? 
* rationale: Although this is the most sensible, it could also mean "count only tags" or other things

#23 COMMENT
* comment nature: [substantial]
* location: 3.18 POP_UPS
* current wording: "If a target attribute is present,..."
* suggested revision: What about JS popups? (window.open)
* rationale: JS popups should be taken into consideration as there are already other JS related verifications

#24 COMMENT
* comment nature: [editorial]
* location: 3.19 PROVIDE_DEFAULTS
* current wording: "If there is no nested option element whose selected attribute is set to some value, warn"
* suggested revision: "If there is no nested option element whose selected attribute is set to _"selected"_, warn"
* rationale: This is the only valid value for this attribute and it's been already included in the next condition of the algorithm

#25 COMMENT
* comment nature: [substantial]
* location: 3.21 STYLE_SHEETS_USE and 2.3.9 Validity
* current wording: If the CSS Style contains at-rules (other than the @media at-rule), properties, or values that are not recognized as being valid CSS Level 1 (2.3.9 Validity), warn
...
CSS 
    A resource is considered a valid CSS resource if it conforms to the grammar defined in [CSS], Appendix B
* suggested revision: The definition of CSS validity should include in some way allowed at-rules, properties and values.
* rationale: Test 3.4 fails for content that is not valid CSS with validity being defined as conforming to the CSS 1 grammar (syntax).
Test 3.21 seems to use the phrase "valid CSS 1" in a sense that is not just grammar conformance.
So right now, CSS 2 that conforms to the CSS 1 grammar passes 3.4, but you'll get a lot of warnings, because the grammar does not define properties and values (3.21)
Additionally,
   @import "foo.css" handheld;
would fail 3.4 because of the media type, which is not part of the CSS 1 grammar, while the rule should be considered when collecting the "Included Resources" (2.3.6).

#26 COMMENT
* comment nature: [editorial]
* location: 3.21 STYLE_SHEETS_USE
* current wording: If the CSS Style contains at-rules (other than the @media at-rule), properties, or values that are not recognized as being valid CSS Level 1 2.3.9 Validity, warn
* suggested revision: Add () around the link "2.3.9 Validity".
* rationale:


Regards,


[1] - [http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/]

Received on Friday, 22 June 2007 16:40:36 UTC