RV: Moki objectInfo attributes joined

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
rendered
>>(an
>>>>> object that isn't supported and its mime type is clearly stated on
>>>>> markup by the type attribute), in this case children elements will
be
>>>>> processed.
>>>>
>>>>I'm wondering: why do we need to store skipped objects in the moki
>>>>document?
>>>>
>>>>Francois.
>>
>>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
a
>>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
objects
>>because they shouldn't be downloaded (we download it to perform the
>>checks). If we remove this information on skipped objects we could
discard
>>loadtype attribute as the objects that will keep HTTPRetrieval
information
>>will be those considered in EXTERNAL_RESOURCES and PAGE_SIZE_LIMIT
tests.
>>
>>Miguel

Received on Thursday, 3 July 2008 15:36:05 UTC