W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > July to September 2008

Re: More clarifications on object processing

From: Jo Rabin <jrabin@mtld.mobi>
Date: Wed, 02 Jul 2008 16:32:29 +0100
Message-ID: <486B9F8D.6030602@mtld.mobi>
To: Francois Daoust <fd@w3.org>
CC: Dominique Hazael-Massieux <dom@w3.org>, public-bpwg-comments <public-bpwg-comments@w3.org>

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

On 02/07/2008 16:16, Francois Daoust wrote:
> Hi Jo,
> 
> Thanks for the reply.
> I think there is still a remaining inconsistency though.
> 
> [in the following examples, the file extensions are supposed to reflect 
> the HTTP Content-Type with which the resources are served]
> 
> Consider the following:
>  <object src="img.gif" type="image/png" />
> 
> Current algorithm says it is mobileOK, since the image is retrieved by 
> 3.15.1 Object Element Processing Rule, and the HTTP Content-Type is 
> "image/gif". I don't quite like it, but as you said: some browsers 
> download "img.gif" in the above example and some don't, so why not say 
> that browsers usually download an object whose type is set to an 
> unsupported mime type.
> 
> 
> Now, in the following:
>  <object src="img.png" type="image/png">
>    <object src="img.gif" type="image/gif" />
>  </object>
> 
> Here, the doc says: "img.png" is retrieved under 3.15.1. Its HTTP 
> Content-Type is neither "image/png" nor "image/jpeg" so we'll move on to 
> the inner object. Fine. Except that "img.png" won't be counted in 3.16 
> PAGE_SIZE_LIMIT (and EXTERNAL_RESOURCES, but since both tests are 
> equivalent, let's focus on PAGE_SIZE_LIMIT). But as opposed to the above 
> example, we're thus saying that browsers usually don't download an 
> object whose type is set to an unsupported mime type.
> 
> 
> In practice, I think we need to make a choice.
> 
> The best choice in my mind is to state that:
> 1. as resolved in April, objects that don't define a type attribute 
> should be retrieved and counted:
> http://www.w3.org/2008/04/17-bpwg-minutes.html#item02
> 2. objects that define a type attribute different from "image/jpeg" and 
> "image/gif" should not be retrieved.
> 
> In terms of changes in the document, I think this would both be easy and 
> clarify the existing text (see how I manage to sell my proposed changes! 
> ;)), because there does not need to be any difference between the 
> objects retrieved under 3.15.1 and those counted in 3.16 PAGE_SIZE_LIMIT 
> (and EXTERNAL_RESOURCES as well).
> 
> This would yield to the following list of changes (that include your 
> proposed changes).
> 
> 
> ===
> 
> PAGE_SIZE_LIMIT
> (removing from your proposed text the mention of exceptions to the 
> 3.15.1 processing rule, as all retrieved objects should be counted)
> 
> Retrieve the document under test, if its size (excluding any 
> redirections discussed under 2.4.3 HTTP Response) exceeds 10 kilobytes, 
> FAIL
> 
> Add to a running total (total size) the size of all the HTTP response 
> bodies that are required to retrieve the document under test (see 2.4.3 
> HTTP Response).
> 
> For each unique included resource (as defined in 2.4.6 Included Resources):
> 
>     Add the size of all the response bodies that are required to 
> retrieve the resource (see 2.4.3 HTTP Response) to the running total. 
> Include in the total all the objects retrieved under the 3.15.1 Object 
> Element Processing Rule.
> 
> If the total size exceeds 20 kilobytes, FAIL
> 
> Note:
> 
> In the case of resources that are referenced more than once in the 
> document under test, and where, as discussed under 2.4.6, they are 
> cached, it is the initial retrieval of that resource (as determined by 
> the first reference in document order) that counts towards the total.
> 
> Note:
> 
> Where the Object Processing Rule (see 3.15.1) yields a resource that is 
> found to be cached, objects that must be assessed in the course of 
> yielding the cached resource count towards the total.
> 
> ===
> 
> Proposed Change to 2.4.3
> (that's your proposal, nothing changed!)
> 
> change the wording of
> 
> Include the size of the response in the total as described under 3.16 
> PAGE_SIZE_LIMIT
> 
> to
> 
> Include the size of the response in the "total size" as described under 
> 3.16 PAGE_SIZE_LIMIT
> 
> in the various places in which it is found.
> 
> ===
> 
> EXTERNAL_RESOURCES
> (removing from your proposed text the mention of exceptions to the 
> 3.15.1 processing rule, as all retrieved objects should be counted)
> 
> Retrieve the resource under test, and add the number of retrievals 
> required to obtain the resource (see 2.4.3 HTTP Response) to a running 
> total.
> 
> For each unique included resource, as defined in 2.4.6 Included Resources:
> 
>     Request the referenced resource
> 
>     Add the number of HTTP requests that are required to retrieve the 
> resource (see 2.4.3 HTTP Response) to the running total. Include in the 
> count all the objects retrieved under the 3.15.1 Object Element 
> Processing Rule.
> 
> If the total exceeds 10, warn
> 
> If this total exceeds 20, FAIL
> 
> ===
> 
> 3.15.1 Object Processing Rule
> (including your proposed addition of caching, and my proposed view to 
> retrieve only objects that don't define a type attribute and those that 
> define a type attribute set to "image/jpeg" or "image/gif"):
> 
> change
> 
>     Retrieve the object (ignoring the type attribute)
>     If the content-type of the retrieved object is "image/jpeg" or 
> "image/gif"
> 
> to
> 
>     If the object element does not define a type attribute, or if the 
> type attribute is set to "image/jpeg" or "image/gif"
>       If the resource is not already cached (see 2.4.6 Included 
> Resources) retrieve the object (ignoring the type attribute)
>     If the type attribute is different from "image/jpeg" and 
> "image/gif", or if the HTTP Content-Type of the retrieved object is not 
> "image/jpef" or "image/gif"
> 
> ===
> 
> Proposed Change to 2.4.6 Included Resources
> 
> Current Text
> 
> Note:
> 
> object elements that are accessed in order to test their Content-Type 
> HTTP header, but do not form part of the ultimate representation of the 
> resource under test (see 3.15 OBJECTS_OR_SCRIPT ), are not considered to 
> be included resources. Their treatment, as regards 3.16 PAGE_SIZE_LIMIT 
> and 3.6 EXTERNAL_RESOURCES , is described in the relevant section.
> 
> Propsoed Text:
> 
> Note:
> 
> Resources that are retrieved according to the processing rules defined 
> in 3.15.1 Object Processing Rules and whose Content-Type HTTP header is 
> not set to image/jpeg or image/gif are not considered to be included 
> resources. Their treatment, as regards 3.16 PAGE_SIZE_LIMIT and 3.6 
> EXTERNAL_RESOURCES, is described in the relevant section.
> 
> 
> Francois.
Received on Wednesday, 2 July 2008 15:33:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:50 UTC