W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > July 2008

RV: Moki objectInfo attributes joined

From: Miguel Garcia <miguel.garcia@fundacionctic.org>
Date: Thu, 3 Jul 2008 17:35:37 +0200
Message-ID: <09700B613C4DD84FA9F2FEA52188281903CEC1BD@ayalga.fundacionctic.org>
To: "public-mobileok-checker" <public-mobileok-checker@w3.org>

Ooops, I've just noticed I responded only to Francois with no copy to
the list.

>>-----Mensaje original-----
>>De: Miguel Garcia
>>Enviado el: jueves, 03 de julio de 2008 14:16
>>Para: 'Francois Daoust'
>>Asunto: RE: Moki objectInfo attributes joined
>>>>-----Mensaje original-----
>>>>De: Francois Daoust [mailto:fd@w3.org]
>>>>Hi, this all looks great!
>>>>See my comment below.
>>>>Miguel Garcia wrote:
>>>>>  - loadtype="SKIPPED": the object resource isn't tasted nor
>>>>> object that isn't supported and its mime type is clearly stated on
>>>>> markup by the type attribute), in this case children elements will
>>>>> processed.
>>>>I'm wondering: why do we need to store skipped objects in the moki
>>OBJECTS_OR_SCRIPTS checks that non supported objects has valid
>>alternatives. That is, object body doesn't consist only on white space
>>chars and if an image is provided as an alternative it is provided in
>>supported format.
>>This information will be recorded in moki in the objectInfo element
>>(content attribute) so we need at least the objectInfo element.
>>Skipped objects are currently recorded in moki with its HTTPRetrieval
>>(http request/ http response) information so we need this value to
>>distinct between objects that will be taken into account for
>>EXTERNAL_RESOURCES and PAGE_SIZE_LIMIT and objects that won't.
>>HTTPRetrieval information perhaps doesn't make sense in skipped
>>because they shouldn't be downloaded (we download it to perform the
>>checks). If we remove this information on skipped objects we could
>>loadtype attribute as the objects that will keep HTTPRetrieval
>>will be those considered in EXTERNAL_RESOURCES and PAGE_SIZE_LIMIT
Received on Thursday, 3 July 2008 15:36:05 UTC

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