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

[minutes] Checker TF Call Wednesday 2 July 2008

From: Francois Daoust <fd@w3.org>
Date: Wed, 02 Jul 2008 16:50:44 +0200
Message-ID: <486B95C4.10401@w3.org>
To: public-mobileok-checker <public-mobileok-checker@w3.org>

Hi,

The minutes of today's call are available at:
http://www.w3.org/2008/07/02-bpwg-minutes.html

... and pasted as text below.


Francois.


02 Jul 2008

    [2]Agenda

       [2] 
http://lists.w3.org/Archives/Public/public-mobileok-checker/2008Jul/0005.html

    See also: [3]IRC log

       [3] http://www.w3.org/2008/07/02-bpwg-irc

Attendees

    Present
           Francois, abel, miguel, dom, Oscar

    Regrets
    Chair
           Abel

    Scribe
           francois

Contents

      * [4]Topics
          1. [5]New grammar validation
          2. [6]Proposed moki for object processing rule
      * [7]Summary of Action Items
      _________________________________________________________



    <trackbot> Date: 02 July 2008

    <scribe> Scribe: francois

    <scribe> ScribeNick: francois

    [Introduction of Oscar]

New grammar validation

    <abel> sorry, this is the agenda
    -->[8]http://lists.w3.org/Archives/Public/public-mobileok-checker/20
    08Jul/0005.html

       [8] 
http://lists.w3.org/Archives/Public/public-mobileok-checker/2008Jul/0005.html

    dom: I sent an email on Monday to state that I implemented the new
    grammar validation algorithm.

    Basically that means we only check XHTML Basic 1.0 and 1.1

    scribe: and XHTML MP 1.0, 1.1, and 1.2
    ... I had to introduce a third state: "not validated"
    ... I also fixed a bug that made the checker fail on unknown DTDs.
    ... Basically, it crashed when it couldn't find the DTD in the
    in-JAR catalog.
    ... I updated the results of the test suites to reflect this

    <dom> [9]Changes in validation algorithm

       [9] http://www.w3.org/mid/1214894494.12088.12.camel@altocumulustier

    miguel: the checker crashes now in some cases where it didn't
    before.

    dom: it might be related to a commit Francois did last week, that
    fixed a Linux bug. Could you check the case more precisely

Proposed moki for object processing rule

    ->
    [10]http://lists.w3.org/Archives/Public/public-mobileok-checker/2008
    Jul/0001.html moki proposal

      [10] 
http://lists.w3.org/Archives/Public/public-mobileok-checker/2008Jul/0001.html

    <abel> actually this is the most recent one-->
    [11]http://lists.w3.org/Archives/Public/public-mobileok-checker/2008
    Jul/0004.html

      [11] 
http://lists.w3.org/Archives/Public/public-mobileok-checker/2008Jul/0004.html

    miguel: introduced new attributes to match the new requirements,
    rendered, tasted
    ... some objects will be tasted and some will be rendered
    ... question is about objects without type attribute

    abel: if the type of the object is set to an unrecognized mime type,
    should we download it, ignore it?

    dom: if the type attribute is set to something different from
    image/gif or image/jpeg, then the object is not going to be tasted.
    ... If there is no type attribute, then the object is going to be
    tasted.

    <dom> on type="foobar" => tasted="false"

    <dom> on no type => tasted="true"

    [francois notes that this is not what the doc says right now, but
    that is what it "should" say]

    <abel> proposal for the moki related to object
    processing->[12]http://lists.w3.org/Archives/Public/public-mobileok-
    checker/2008Jul/0004.html

      [12] 
http://lists.w3.org/Archives/Public/public-mobileok-checker/2008Jul/0004.html

    dom: have you seen the reply I made to your proposal? Main question
    is about images. Do you plan to add rendered as well to images?

    <dom>
    [13]http://lists.w3.org/Archives/Public/public-mobileok-checker/2008
    Jul/0006.html

      [13] 
http://lists.w3.org/Archives/Public/public-mobileok-checker/2008Jul/0006.html

    dom: "Tasted" a priori doesn't apply to images, but "rendered" does

    abel: "isBlank" is for something in the Object Processing rule.

    dom: I would prefer a single attribute, as it's easier to parse and
    read.

    <abel> isEmpty is about OBJECTS_SCRIPT-5

    <abel> isBlank is about OBJECTS_SCRIPT-6 and so on

    <dom> tasted=true + rendered=true , tasted=false + rendered=false,
    tasted=true + rendered=false

    dom: I think we should also do it for rendered and tasted. One
    attribute to rule them all.

    <dom> so we should have only one attribuet like "loadtype" with
    three values: tasted, rendered, none

    miguel: If you think that's easier, I don't see any problem

    dom: yes, I think it's easier to parse only one attribute as there
    are only three possibilities here

    miguel: ok, not sure about tasted/rendered as they are not
    exclusive.

    <dom> [so 2 attributes instead of 5]

    dom: I don't see how you could have something rendered that is not
    tasted.

    miguel: we could try and check if we run into troubles.

    dom: yes. Anyway, it's mostly cosmetic.

    miguel: Regarding images, you asked if images should have the same
    kind of attributes.
    ... In the moki, we'll have only images that are going to be
    rendered.
    ... no need to include the images that are only tasted.

    dom: I think you're right indeed.

    <dom> <object data="image.gif" /> <img src="image.gif" />

    dom: you'll be able to make sure that the image will be counted only
    once in the example I just pasted?

    miguel: yes.
    ... We won't count images that are already encountered as objects

    <abel> <object src"img.gif type="image/gif></object>

    abel: this object is an object and has no alternatives. No warning
    and no failures in the current document.

    dom: I think it's the same problem that we're not checking that
    images have "alt" attributes.
    ... Related to the NON-TEXT_ALTERNATIVES text on real images.
    ... Initially, there was the same kind of thing in
    OBJECTS_OR_SCRIPT, but we're not testing this anymore.

    <dom> abel: but we *are* checking the alt attribute

    <dom> dom: oh, right

    <dom> ... I guess we lost that when we rewrote the object_or_script
    test

    francois: wouldn't the "warning" on empty element apply here?

    abel: no, because it only applies to images that are not
    "image/jpeg" or "image/gif"

    dom: That's correct. At this point, given the difficulty to get this
    algorithm right, I would suggest we simply ignore this for the time
    being.

    abel: I think a warning would be needed.

    dom: I guess we could mention it to Jo. I don't think it would
    trigger another Last Call, as it's just an editorial "mistake".
    ... If it's too complicated to change the wording, I guess we should
    forget about it.
    ... The cost of doing it may be higher than the benefit it brings (a
    warning in this case)

    <dom> ACTION: Abel to send a note to Jo about the lack of warning on
    empty GIF/JPEG objects [recorded in
    [14]http://www.w3.org/2008/07/02-bpwg-minutes.html#action01]

    <trackbot> Created ACTION-805 - Send a note to Jo about the lack of
    warning on empty GIF/JPEG objects [on Abel Rionda - due 2008-07-09].

    dom: I think we can leave it for Jo to decide whether it needs to be
    fixed or not.

    abel: ok

    miguel: ok

    abel: wondering whether all images in an object need to be
    supported, or if some of them is enough?

    dom: All of them need to be supported in the current algorithm, and
    that's intended.
    ... Do you have any estimate when you may have a first version of
    the implementation of these changes available?

    abel: It should be finished for the next call. Beginning of next
    week, actually.
    ... For Monday, for sure.

    dom: I'll personally be on vacation starting tomorrow night, but I
    guess Francois can review this.

    [call adjourned]

Summary of Action Items

    [NEW] ACTION: Abel to send a note to Jo about the lack of warning on
    empty GIF/JPEG objects [recorded in
    [15]http://www.w3.org/2008/07/02-bpwg-minutes.html#action01]

    [End of minutes]
Received on Wednesday, 2 July 2008 14:51:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 2 July 2008 14:51:18 GMT