More clarifications on object processing

HI,

WHILE IMPLEMENTING THE NEW LAST CALL VERSION OF MOBILEOK, I
FOUND A FEW
PLACES WHERE THE PROCESSING OF THE OBJECTS COULD BE
CLARIFIED:
* WHEN ANALYZING EXTERNAL RESOURCES (IN
CONTENTFORMATSUPPORT,
PAGESIZELIMIT, EXTERNALRESOURCES), THE OBJECTS AND IMAGES
THAT ARE SET
AS FALLBACK OF AN OBJECT THAT IS IN AN ACCEPTABLE FORMAT
SHOULDN'T BE
COUNTED. FOR INSTANCE,
<OBJECT DATA="MYIMAGE.GIF"><IMG
SRC="MYIMAGE.PNG"
ALT=""/></OBJECT>
SHOULDN'T TRIGGER AN ERROR IN CONTENTFORMATSUPPORT, THE
WEIGHT OF
MYIMAGE.PNG SHOULDN'T BE COUNTED IN PAGESIZELIMIT AND
EXTERNALRESOURCES
* SIMILARLY, I DON'T THINK WE WANT TO RAISE A
CONTENTFORMATSUPPORT ERROR
ON <OBJECT DATA="MYIMAGE.PNG"><IMG
SRC="MYIMAGE.GIF" ALT=""
/></OBJECT>
SINCE THIS IS USING CORRECTLY THE FALLBACK MECHANISM; WHILE
THIS GETS
ACCEPTED BY OBJECTSORSCRIPT, THIS WOULD CURRENTLY RAISE AN
ERROR IN THE
WAY I READ CONTENTFORMATSUPPORT; 
* I DON'T THINK "MYIMAGE.GIF" SHOULD BE COUNTED AS
EXTERNAL
RESOURCES/PAGE SIZE LIMIT IN THE FOLLOWING INSTANCE:
<OBJECT DATA="MYIMAGE.GIF"
TYPE="IMAGE/PNG">HELLO</OBJECT> - THE
CURRENT
TEXT SAYS TO "INCLUDE THOSE OBJECTS WHOSE CONTENT TYPE
IS EITHER
"IMAGE/JPEG" OR "IMAGE/GIF" IRRESPECTIVE
OF WHETHER THE TYPE ATTRIBUTE
IS SPECIFIED.", BUT IT'S NOT CLEAR WHY.
* IF I HIT AN HTTP REDIRECT, DOES THE SIZE OF THE PAGE
SERVED AS THE
REDIRECT PAGE COUNTS IN PAGE_SIZE_LIMIT-1 OR ONLY
UNDER ?¿PAGE_SIZE_LIMIT-2? I'VE IMPLEMENTED THE LATTER SINCE
I FIND IT
LESS CONFUSING, BUT THE SPEC COULD BE CLEARER ABOUT IT

DOM

Hi Dom,

See inline for some comments on your comments, with a view
to 
identifying precisely the bits that may need clarification.

Francois.


Dominique Hazael-Massieux wrote:
[...]
> While implementing the new last call version of
mobileOK, I found a few
> places where the processing of the objects could be
clarified:

> * when analyzing external resources (in
ContentFormatSupport,
> PageSizeLimit, ExternalResources), the objects and
images that are set
> as fallback of an object that is in an acceptable
format shouldn't be
> counted. For instance,
> <object data="myimage.gif"><img
src="myimage.png"
alt=""/></object>
> shouldn't trigger an error in ContentFormatSupport, the
weight of
> myimage.png shouldn't be counted in PageSizeLimit and
ExternalResources

Part to clarify:
  "object means "object" and "img"
in the note on objects to include in 
2.4.6 Included Resources"

The additional note introduced in the latest version in
2.4.6 Included 
Resources:
 
http://www.w3.org/TR/2008/WD-mob
ileOK-basic10-tests-20080610/#included_resources

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

... was meant to address this particular problem.

In the following example: <object
data="myimage.gif"><object 
data="myimage.png">Blah</object></obje
ct>, the behavior is correct 
right? "myimage.png" is not taken into account in
ContentFormatSupport, 
PageSizeLimit and ExternalResources, as should be expected.

The point in your example is we're only talking about
"object" elements 
in the note whereas in this case, the "object"
element should be 
regarded as encompassing "img" elements as well,
am I correct? This 
should be noted (as the note that appears right before the
above quoted 
one suggests: "In some circumstances object elements
may act as synonyms 
for other elements such as img and iframe. In these cases it
is noted in 
the relevant section when to regard object elements as
equivalents for 
other elements.").



> * similarly, I don't think we want to raise a
ContentFormatSupport error
> on <object data="myimage.png"><img
src="myimage.gif" alt=""
/></object>
> since this is using correctly the fallback mechanism;
while this gets
> accepted by ObjectsOrScript, this would currently raise
an error in the
> way I read ContentFormatSupport; 

Part to clarify:
  "ultimate representation of the resource under
test"

[Side note:
The Accept header precises that only image/gif and
image/jpeg are supported.
Is it still correct to send a PNG image even with a fallback
mechanism?
I think it is, I'm raising the point in case it's not...]

 From the note above, since "myimage.png" does
"not form part of the 
ultimate representation of the resource under test",
the test should not 
apply on "myimage.png".


> * I don't think "myimage.gif" should be
counted as external
> resources/page size limit in the following instance:
> <object data="myimage.gif"
type="image/png">Hello</object> - the
current
> text says to "include those objects whose content
type is either
> "image/jpeg" or "image/gif"
irrespective of whether the type attribute
> is specified.", but it's not clear why.

Part to clarify:
  The note on how to select objects at the beginning of 
EXTERNAL_RESOURCES and PAGE_SIZE_LIMIT

It may deserve clarification, but this restriction applies
to the set of 
"objects retrieved under the 3.15.1 Object Element
Processing Rule". An 
object with an "image/png" type won't be retrieved
by the Object Element 
Processing Rule, so "myimage.gif" won't be
counted.



> * if I hit an HTTP redirect, does the size of the page
served as the
> redirect page counts in PAGE_SIZE_LIMIT-1 or only
> under PAGE_SIZE_LIMIT-2? I've implemented the latter
since I find it
> less confusing, but the spec could be clearer about it

Part to clarify:
  2.4.3 HTTP_RESPONSE
  3.16 PAGE_SIZE_LIMIT

Suggestion:
  In 2.4.3 HTTP_RESPONSE, precise the total to which the
size of the 
response should be included (I propose the second as well)
  In 3.16 PAGE_SIZE_LIMIT, link back to 2.4.3 HTTP_RESPONSE
to precise 
what we mean by "the size of the document" and
"the size of the response 
body". This would be consistent with 3.6
EXTERNAL_RESOURCES that 
includes such a link.

LE JEUDI 12 JUIN 2008 à 17:37 +0200, FRANCOIS DAOUST A éCRIT
:
> DOMINIQUE HAZAEL-MASSIEUX WROTE:
> > * WHEN ANALYZING EXTERNAL RESOURCES (IN
CONTENTFORMATSUPPORT,
> > PAGESIZELIMIT, EXTERNALRESOURCES), THE OBJECTS AND
IMAGES THAT ARE SET
> > AS FALLBACK OF AN OBJECT THAT IS IN AN ACCEPTABLE
FORMAT SHOULDN'T BE
> > COUNTED. FOR INSTANCE,
> > <OBJECT DATA="MYIMAGE.GIF"><IMG
SRC="MYIMAGE.PNG"
ALT=""/></OBJECT>
> > SHOULDN'T TRIGGER AN ERROR IN
CONTENTFORMATSUPPORT, THE WEIGHT OF
> > MYIMAGE.PNG SHOULDN'T BE COUNTED IN PAGESIZELIMIT
AND EXTERNALRESOURCES
> 
> PART TO CLARIFY:
>   "OBJECT MEANS "OBJECT" AND
"IMG" IN THE NOTE ON OBJECTS TO INCLUDE IN 
> 2.4.6 INCLUDED RESOURCES"

YES, I AGREE THAT REPLACING "OBJECT ELEMENTS" WITH
"OBJECT AND IMG
ELEMENTS" IN THE NOTE UNDER 2.4.6 SHOULD SUFFICE TO
CLARIFY THE
SITUATION.

IN THE SAID NOTE (COPIED BELOW):
> "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 ), "

.... IT WOULD BE NICE IF "?¿FORM[ING] PART OF THE
ULTIMATE REPRESENTATION"
WAS ACTUALLY DEFINED (IN 3.15.1, MOST PROBABLY).

> > * SIMILARLY, I DON'T THINK WE WANT TO RAISE A
CONTENTFORMATSUPPORT ERROR
> > ON <OBJECT
DATA="MYIMAGE.PNG"><IMG
SRC="MYIMAGE.GIF" ALT=""
/></OBJECT>
> > SINCE THIS IS USING CORRECTLY THE FALLBACK
MECHANISM; WHILE THIS GETS
> > ACCEPTED BY OBJECTSORSCRIPT, THIS WOULD CURRENTLY
RAISE AN ERROR IN THE
> > WAY I READ CONTENTFORMATSUPPORT; 
> 
> PART TO CLARIFY:
>   "ULTIMATE REPRESENTATION OF THE RESOURCE UNDER
TEST"
> 
> [SIDE NOTE:
> THE ACCEPT HEADER PRECISES THAT ONLY IMAGE/GIF AND
IMAGE/JPEG ARE SUPPORTED.
> IS IT STILL CORRECT TO SEND A PNG IMAGE EVEN WITH A
FALLBACK MECHANISM?
> I THINK IT IS, I'M RAISING THE POINT IN CASE IT'S
NOT...]

(THAT'S ACTUALLY THE GIST OF MY COMMENT, I THINK 

>  FROM THE NOTE ABOVE, SINCE "MYIMAGE.PNG"
DOES "NOT FORM PART OF THE 
> ULTIMATE REPRESENTATION OF THE RESOURCE UNDER
TEST", THE TEST SHOULD NOT 
> APPLY ON "MYIMAGE.PNG".

THAT IS TRUE, INDEED; BUT THIS REITERATES THE NEED FOR
CLARIFYING
"ULTIMATE REPRESENTATION OF THE RESOURCE UNDER
TEST" (AS YOU NOTE). 


> > * I DON'T THINK "MYIMAGE.GIF" SHOULD BE
COUNTED AS EXTERNAL
> > RESOURCES/PAGE SIZE LIMIT IN THE FOLLOWING
INSTANCE:
> > <OBJECT DATA="MYIMAGE.GIF"
TYPE="IMAGE/PNG">HELLO</OBJECT> - THE
CURRENT
> > TEXT SAYS TO "INCLUDE THOSE OBJECTS WHOSE
CONTENT TYPE IS EITHER
> > "IMAGE/JPEG" OR "IMAGE/GIF"
IRRESPECTIVE OF WHETHER THE TYPE ATTRIBUTE
> > IS SPECIFIED.", BUT IT'S NOT CLEAR WHY.
> 
> PART TO CLARIFY:
>   THE NOTE ON HOW TO SELECT OBJECTS AT THE BEGINNING OF

> EXTERNAL_RESOURCES AND PAGE_SIZE_LIMIT
> 
> IT MAY DESERVE CLARIFICATION, BUT THIS RESTRICTION
APPLIES TO THE SET OF 
> "OBJECTS RETRIEVED UNDER THE 3.15.1 OBJECT ELEMENT
PROCESSING RULE". AN 
> OBJECT WITH AN "IMAGE/PNG" TYPE WON'T BE
RETRIEVED BY THE OBJECT ELEMENT 
> PROCESSING RULE, SO "MYIMAGE.GIF" WON'T BE
COUNTED.

I THINK THERE IS A RISK OF CONFUSION ON THE MEANING OF
"TYPE" HERE:
 * THERE IS THE ACTUAL CONTENT-TYPE UNDER WHICH THE IMAGE IS
SERVED (AND
WHICH IS AUTHORITATIVE)
 * AND THERE IS THE TYPE ATTRIBUTE ON THE <OBJECT>
ELEMENT, WHICH SERVES
AS A HINT TO BROWSERS TO DETERMINE WHETHER THEY NEED TO
BOTHER
DOWNLOADING THE REFERENCED IMAGE

ASSUMING THAT MYIMAGE.GIF IS INDEED A GIF IMAGE (AND SERVED
AS SUCH IN
HTTP), BUT THAT THE HINT GIVEN IN THE TYPE ATTRIBUTE IS
WRONG (SET TO
IMAGE/PNG), MY READING OF THE CURRENT ALGORITHM IS THAT
MYIMAGE.GIF
WOULD BE COUNTED IN THE PAGE_SIZE_LIMIT AND
EXTERNAL_RESOURCES SINCE
3.15.1 SAYS TO INCLUDE GIF AND JPEG IMAGES
"IRRESPECTIVE OF WHETHER THE
TYPE ATTRIBUTE IS SPECIFIED".

I THINK THAT A GIF IMAGE EMBEDDED IN AN OBJECT WITH A TYPE
ATTRIBUTE SET
TO "IMAGE/PNG" WOULDN'T ACTUALLY BE PART OF THE
ULTIMATE REPRESENTATION
OF THE DOCUMENT; THE CURRENT ALGORITHM SUGGESTS THAT IT
WOULD.

> > * IF I HIT AN HTTP REDIRECT, DOES THE SIZE OF THE
PAGE SERVED AS THE
> > REDIRECT PAGE COUNTS IN PAGE_SIZE_LIMIT-1 OR ONLY
> > UNDER ?¿PAGE_SIZE_LIMIT-2? I'VE IMPLEMENTED THE
LATTER SINCE I FIND IT
> > LESS CONFUSING, BUT THE SPEC COULD BE CLEARER
ABOUT IT
> 
> PART TO CLARIFY:
>   2.4.3 HTTP_RESPONSE
>   3.16 PAGE_SIZE_LIMIT
> 
> SUGGESTION:
>   IN 2.4.3 HTTP_RESPONSE, PRECISE THE TOTAL TO WHICH
THE SIZE OF THE 
> RESPONSE SHOULD BE INCLUDED (I PROPOSE THE SECOND AS
WELL)
>   IN 3.16 PAGE_SIZE_LIMIT, LINK BACK TO 2.4.3
HTTP_RESPONSE TO PRECISE 
> WHAT WE MEAN BY "THE SIZE OF THE DOCUMENT"
AND "THE SIZE OF THE RESPONSE 
> BODY". THIS WOULD BE CONSISTENT WITH 3.6
EXTERNAL_RESOURCES THAT 
> INCLUDES SUCH A LINK.

AGREED.

DOM

 Dear Dominique Hazael-Massieux ,

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 (Fourth Last Call) published on 10 Jun 2008. 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, and has
been implemented in the new version of the document
available at:
http://www.w3.org/2005/MWI/BPWG/Gr
oup/Drafts/mobileOK-Basic-1.0-Tests/080707r.

Please review it carefully and let us know by email at
public-bpwg-commentsw3.org if you agree with it or not before
5 August
2008. 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,
Dominique Hazaël-Massieux
François Daoust
W3C Staff Contacts

 1. http://
www.w3.org/mid/1213203871.6545.1.camellocalhost
 2. http://www.w3.org/TR/2008/WD-mobileOK-basic10-tests
-20080610/


=====

Your comment on 2.4.6 Included Resources:
> * when analyzing external resources (in
ContentFormatSupport,
> PageSizeLimit, ExternalResources), the objects and
images that are set
> as fallback of an object that is in an acceptable
format shouldn't be
> counted. For instance,
> <object data="myimage.gif"><img
src="myimage.png"
alt=""/></object>
> shouldn't trigger an error in ContentFormatSupport, the
weight of
> myimage.png shouldn't be counted in PageSizeLimit and
ExternalResources


Working Group Resolution (LC-1978):
We agree that the "myimage.png" should not trigger
a
CONTENT_FORMAT_SUPPORT error, and should not be taken into
account in
PAGE_SIZE_LIMIT and EXTERNAL_RESOURCES. This is triggered by
the note in
2.4.6 Included Resources:
 "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".

We agree that the notion of "ultimate representation of
the resource"
deserves to be clarified though and the note extended to
resources
retrieved by section 3.15.1 Object Element Processing Rule.

On the light of the discussion that followed your other
comment (LC-1980)
on the use of the HTTP Content-Type value to taste object
element, we
updated the note to specify that only resources retrieved
under the 3.15.1
Object Element Processing Rule whose Content-Type is
image/gif or
image/jpeg are considered to be Included Resources:
http://www.w3.or
g/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707
r#included_resources

----

Your comment on 2.4.6 Included Resources:
> * similarly, I don't think we want to raise a
ContentFormatSupport
> error
> on <object data="myimage.png"><img
src="myimage.gif" alt=""
> /></object>
> since this is using correctly the fallback mechanism;
while this gets
> accepted by ObjectsOrScript, this would currently raise
an error in
> the
> way I read ContentFormatSupport;


Working Group Resolution (LC-1979):
We agree that the example should not raise a FAIL in
CONTENT_FORMAT_SUPPORT, because "myimage.png" does
not form part of the
ultimate representation of the resource under test, as noted
in 2.4.6
Included Resources.

We clarified the note in 2.4.6 Included Resources as noted
in our reply to
your previous comment (LC-1978) on the need to clarify which
objects and
images are Included Resources, and which are not.

----

Your comment on 3.16 PAGE_SIZE_LIMIT:
> * I don't think "myimage.gif" should be
counted as external
> resources/page size limit in the following instance:
> <object data="myimage.gif"
type="image/png">Hello</object> - the
> current
> text says to "include those objects whose content
type is either
> "image/jpeg" or "image/gif"
irrespective of whether the type attribute
> is specified.", but it's not clear why.


Working Group Resolution (LC-1980):
We understand that point, but note that there is not a real
consistency in
the way such objects are handled by mobile browsers in
practice.

Some browsers download all the objects and use the HTTP
Content-Type
header irrespective of the presence of the type attribute,
while other
browsers follow the type attribute and only download objects
that match
values of the HTTP Accept header.

We think Content Providers should "benefit" (or
rather should not be
"punished") for this lack of consistency in mobile
browsers, and decided,
in the interest of returning fewer FAIL messages:
1/ to stick to the HTTP Content-Type header to determine
whether an object
is rendered or the fallback mechanism has to be used.
2/ to stick to our decision not to count objects that define
a type
attribute not set to image/gif or image/jpeg in
PAGE_SIZE_LIMIT and
EXTERNAL_RESOURCES.

However, since we recognize that the corresponding behavior
among mobile
browsers is not consistent, that it is a bad practice to
have a type
attribute that does not match the Content-Type of the
underlying resource
and that it is a good practice to define the type attribute,
we also
introduced two additional warning messages:
"If there is no type attribute, warn"
"If the Internet media type of the retrieved resource,
as indicated by its
Content-Type HTTP header does not match that stated in the
type attribute,
warn"

We note that our decision introduces a slight inconsistency
in the way
objects are treated by the specification: on the one hand,
section 3.15.1
Object Element Processing Rule says that the Object must be
retrieved so
that the HTTP Content-Type header may be parsed, on the
other hand,
section 3.16 PAGE_SIZE_LIMIT (resp. 3.6 EXTERNAL_RESOURCES)
says that an
object defined with a type attribute set to image/png does
not count as a
retrieved resource (provided its actual Content-Type is not
image/gif or
image/jpeg). We think that it is needed though for the above
mentioned
reasons.

----

Your comment on 3.16 PAGE_SIZE_LIMIT:
> * if I hit an HTTP redirect, does the size of the page
served as the
> redirect page counts in PAGE_SIZE_LIMIT-1 or only
> under PAGE_SIZE_LIMIT-2? I've implemented the latter
since I find
> it
> less confusing, but the spec could be clearer about it


Working Group Resolution (LC-1981):
Yes, we agree that the text here deserved to be clarified.
We updated the
text consequently:

- Section 3.16 PAGE_SIZE_LIMIT was clarified with regards to
the treatment
of HTTP response bodies that are required to retrieve a
resource:
http://www.w3.org/2
005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#P
AGE_SIZE_LIMIT

- Section 2.4.3 HTTP Response was also amended to have the
reader refer to
3.16 PAGE_SIZE_LIMIT (resp. 3.6 EXTERNAL_RESOURCES) for
details of the
total size (resp. count) the HTTP redirect response body
should be added
to:
http://www.w3.org/200
5/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#htt
p_response

----