Re: More clarifications on object processing

Gosh this is hard to get right ... I missed a warn in the proposed 
Object Element Processing Rule:

New Proposed Text

3.15.1 Object Element Processing Rule

Proposed Text

For each object element that has no object element ancestor in this
context (excepting the context node itself):

     If there is no type attribute, warn

     If the object element is empty, warn

     If the content of the object element consists only of white space, FAIL

     Retrieve the referenced resource (ignoring the type attribute)

 If the content type of the retrieved resource is not "image/jpeg" or 
"image/gif", warn

 If the content type of the retrieved resource does not match that 
stated in the type attribute, warn

         For each img element that has no object element ancestor in this
context:

             If the content type of the img element is not "image/jpeg"
or "image/gif", FAIL

         Reapply this rule using the current object element as the context

     Note

     A warning is issued when the content type is not compatible with the
Default Delivery Context because some user agents do not take into
account the type attribute of object elements and this may cause the
user agent to retrieve very large incompatible objects with consequences
to performance and cost.

     Note

     A 406 status on retrieval of a resource referenced by an object
element does not constitute a FAIL.


[also make corresponding change to 2.4.3 HTTP Response]




On 03/07/2008 14:49, Jo Rabin wrote:
> 
> [cc public bpwg - don't think this has been aired there]
> 
> OK, thinking about this a bit more ... and following off-line discussion 
> with the esteemed Francois Daoust ...
> 
> ... I have a new proposal on 3.15.1 Object Processing Rule which takes 
> into account the point made by Abel on the checker list
> 
> http://lists.w3.org/Archives/Public/public-mobileok-checker/2008Jul/0010.html 
> 
> 
> also please see
> 
> http://lists.w3.org/Archives/Public/public-bpwg-comments/2008JulSep/0000.html 
> 
> 
> for a more complete list of proposed changes that are relevant to this.
> 
> 
> Also I have spotted that 3.13 NO_FRAMES could do with clarification in 
> this context too and that 3.7 GRAPHICS_FOR_SPACING and 3.9 
> IMAGES_RESIZING and IMAGES_SPECIFY_SIZE need clarification ref handling 
> of the type attribute.
> 
> 
> ===
> 
> NO_FRAMES
> 
> Proposed Text
> 
> If the document contains a frame , frameset or iframe element, FAIL
> 
> Current Text
> 
> If the document contains a frame , frameset or iframe element or it 
> contains an object element which when retrieved has an Internet media 
> type that starts with "text/", "application/xhtml+xml" or 
> "application/vnd.wap.xhtml+xml", FAIL
> 
> 
> ===
> 
> make 3.7 and 3.9 consistent
> 
> 3.7 GRAPHICS_FOR_SPACING
> 
> ...
> 
> For each img element and object element which when retrieved has an 
> Internet media type that starts with "image/":
> 
> ...
> 
> 3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE
> 
> current text:
> 
> ...
> 
> For each img element and object element whose type attribute starts with 
> "image/":
> 
> ...
> 
> proposed text:
> 
> 
> For each img element and object element which when retrieved has an 
> Internet media type that starts with "image/":
> 
> 
> 
> ===
> 3.15.1 Object Element Processing Rule
> 
> Proposed Text
> 
> For each object element that has no object element ancestor in this 
> context (excepting the context node itself):
> 
>     If there is no type attribute, warn
> 
>     If the object element is empty, warn
> 
>     If the content of the object element consists only of white space, FAIL
> 
>     Retrieve the referenced resource (ignoring the type attribute)
> 
>     If the content type of the retrieved object is not "image/jpeg" or 
> "image/gif", warn
> 
>         For each img element that has no object element ancestor in this 
> context:
> 
>             If the content type of the img element is not "image/jpeg" 
> or "image/gif", FAIL
> 
>         Reapply this rule using the current object element as the context
> 
>     Note
> 
>     A warning is issued when the content type is not compatible with the 
> Default Delivery Context because some user agents do not take into 
> account the type attribute of object elements and this may cause the 
> user agent to retrieve very large incompatible objects with consequences 
> to performance and cost.
> 
>     Note
> 
>     A 406 status on retrieval of a resource referenced by an object 
> element does not constitute a FAIL.
> 
> 
> [also make corresponding change to 2.4.3 HTTP Response]
> 
> 
> Current Text
> 
> For each object element that has no object element ancestor in this 
> context (excepting the context node itself):
> 
>     Retrieve the object (ignoring the type attribute)
> 
>     If the content type of the retrieved object is not "image/jpeg" or 
> "image/gif"
> 
>         If the object element is empty, warn
> 
>         If the content of the object element consists only of white 
> space, FAIL
> 
>         For each img element that has no object element ancestor in this 
> context:
> 
>             If the content type of the img element is not "image/jpeg" 
> or "image/gif", FAIL
> 
>         Reapply this rule using the current object element as the context
> 
> 
> 
> 
> On 02/07/2008 16:32, Jo Rabin wrote:
>>
>> Francois I don't object to this approach but did point out this self 
>> same apparent inconsistency in the draft before the last last call. 
>> The reason, as discussed, for this apparent inconsistency is that we 
>> are not modelling any particular User Agent, we are giving the content 
>> provider the best chance of a pass. If we are to reverse that earlier 
>> decision then I think we need to be clear as to why and what 
>> consequences that has for PASS/FAIL.
>>
>> If anything, my preference would be to have an additional WARN if the 
>> retrieved content type does not match the advertised type, including 
>> not advertising a type, and leave it at that.
>>
>> Jo
>>
>

Received on Thursday, 3 July 2008 13:59:09 UTC