[minutes] Checker TF Call Wednesday 25 June 2008

Hi guys,

The minutes of yesterday's call are available at:
... and copied as text below.

We went through the list of remaining bugs, and checked how to address 
(and who could do it).

Oscar, I would suggest that you subscribe to the checker task force 
mailing-list. In order to do so, you may use one of the following methods:
1. Follow the "subscribe to this list" link on:
2. Send an email to public-mobileok-checker-request@w3.org whose subject 
is "subscribe"
3. ask me!

Feel free to jump in for clarifications and/or if you want to be part of 
this bug-fixing party! ;)


25 Jun 2008



    See also: [3]IRC log

       [3] http://www.w3.org/2008/06/25-bpwg-irc


           abel, miguel, Dom, francois



    -> [4]http://www.w3.org/Bugs/Public/show_bug.cgi?id=5006 bug 5006
    "Does a "tidied" element or attribute exist? "

       [4] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5006

    abel: the goal of this was to inform the user whether the test was
    run on a tidied version of the document or not
    ... but that's not required by mobileOK
    ... so it's up to us to decide

    dom: I think we should move it as "enhancement" and re-assign it
    ... I'll take it

    abel: sounds good

    -> [5]http://www.w3.org/Bugs/Public/show_bug.cgi?id=5015 bug 5015
    Need working example for accessing line number in XSL

       [5] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5015

    abel: in Java, we can access the line number
    ... but that's not available in XSLT
    ... since it doesn't work on a DOM tree
    ... I don't think we can do much about it



    dom: I think Saxon has an extension to get the line number
    ... but it didn't work when Roland tried, as far as I remember
    ... let's close it for now and see if we have time for this in the

    abel: agreed

    -> [7]http://www.w3.org/Bugs/Public/show_bug.cgi?id=5421 bug 5421
    URI resolution doesn't take <base href> into account

       [7] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5421

    abel: does this still need more work?

    dom: the Java code is OK - remains to check that this works
    correctly for XSLT

    abel: we have checked the Java code and it is indeed fixed
    ... but what happens when there is more than one base tag?

    dom: I think using the first <base> is ok
    ... ; (nothing that more than one <base> is not valid)
    ... I still need to look at the some of the XSLT cases where further
    URI resolution is needed

    -> [8]http://www.w3.org/Bugs/Public/show_bug.cgi?id=5590 bug 5590
    Record more detail about source of an image/object retrieval

       [8] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5590

    -> [9]http://www.w3.org/Bugs/Public/show_bug.cgi?id=5774 bug 5574
    Object Rule Processing

       [9] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5774

    abel: we're not sure about 5590

    Jun/0005.html Dom's message re 5590


    abel: from what we understand, we need to annotate the objects that
    are really rendered in moki
    ... not sure about having to annotate whether images come from style

    dom: [trying to summarize his message]

    miguel: we think it would be better if we filter objects and images
    that are tasted or rendered in the moki

    <objectInfo rendered="false" tasted="true" />

    <object data="foo.png"><img src="foo.gif" /></object>

    <object data="foo.png" type="image/png"><img src="foo.gif"

    <Zakim> francois, you wanted to ask for clarification about
    "rendered eq false and tasted eq false"

    loadtype="tasted" loadtype="rendered"

    loadtype="tasted" vs loadtype="rendered"

    reads "In the following, include in the total only those objects
    retrieved under the 3.15.1 Object Element Processing Rule whose type
    attribute is not specified, and those whose content type is either
    "image/jpeg" or "image/gif" irrespective of whether the type
    attribute is specified. "

      [11] http://www.w3.org/TR/mobileOK-basic10-tests/#PAGE_SIZE_LIMIT

    dom: I have implemented in XSLT - doable with XPath, more difficult
    through the DOM AFAICT

    [detection of tasted in XSLT:
    eok/basic/xslt/includedResources.xsl ]


    [detection of rendered:
    eok/basic/xslt/ObjectsOrScriptTest.xsl ]


    dom: any idea about schedule on this bug?

    abel: we're targeting mid-July, right?
    ... we'll start working on this beginning of next week - hopefully
    we can finish it in ~10 days
    ... if you guys can help with some of the other bugs, it would be
    ... esp. with 5775 grammar validation

    dom: sounds good; francois and I will try to tackle 5775

    -> [14]http://www.w3.org/Bugs/Public/show_bug.cgi?id=5591 Handling
    of Meta Refresh

      [14] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5591

    abel: think we should close it

    dom: probably more part of UI than library
    ... I'll take it and move it to the Web UI component

    -> [15]http://www.w3.org/Bugs/Public/show_bug.cgi?id=5762 Media
    rules check in linked CSS (StylesheetUseTest)

      [15] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5762

    Abel: I think we need to review better the StylesheetUse test

    Miguel: that test tries to check that at least one style sheet is
    used for handheld devices
    ... in the XSLT, we check the media attribute of the <link> tag
    ... but we don't check the content of the style sheet

    dom: so, if the entire style sheet is enclosed in @media screen { },
    the checker won't notice anything

    -> [16]http://www.w3.org/TR/mobileOK-basic10-tests/#STYLE_SHEETS_USE
    "If all styles are restricted to media types other than "handheld"
    or "all" by means of @media at-rules, warn "

      [16] http://www.w3.org/TR/mobileOK-basic10-tests/#STYLE_SHEETS_USE

    scribe: indeed, the mobileOK spec says we should warn on this
    ... so yes, I agree we should be checking this as well

    miguel: so we need to change the preprocessor and the XSLT
    ... we'll be dealing with it

    -> [17]http://www.w3.org/Bugs/Public/show_bug.cgi?id=5763
    xml-stylesheet processing instructions

      [17] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5763

    abel: this one requires changes to the Java code too
    ... we'll take that one too - hopefully won't take too long

    -> [18]http://www.w3.org/Bugs/Public/show_bug.cgi?id=5764 i18n

      [18] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5764

    abel: we can do the Spanish translations, you guys could do the
    French one
    ... but obviously, this has a lower priority

    dom: indeed; but let's leave it for after the release

    -> [19]http://www.w3.org/Bugs/Public/show_bug.cgi?id=5765

      [19] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5765

    abel: same for that one

    <francois> [I would add that having more semantics in the info
    returned by the checker should also have more priority than i18n

    abel: hopefully there isn't that much work to do on that one

    dom: let's meet next week

    abel: ok
    ... what about the vodafone's contributor?
    ... I got a mail from Oscar last week
    ... I gave him information about our ongoing work, but I didn't get
    a response

    dom: dan confirmed that he was allowed to work, and nominated him to
    the group
    ... ping him again by email, and copy francois and I, maybe?

    <francois> [I will contact him as well to have him subscribe to the

    abel: ok, will do and inform him of our call next week






    [discussions on getting the test suite to work]

    dom: I think there must be a bug in the preprocessor
    ... the length of the content detected shouldn't vary from a
    platform to another
    ... (typically, this could make a page fail on Windows and gets a
    mobileOK on linux - which doesn't make sense)

    miguel: the problem is not in the preprocessor, but in tomcat

    dom: ok, I hadn't understood this
    ... do you know whether we can configure tomcat not to behave

    miguel: it's related to line-feed vs carriage return characters
    ... we can check if removing carriage return characters help

    dom: ok... would still be good to fix at some point, but I can guess
    we can live with it for the time being

    [End of minutes]

Received on Thursday, 26 June 2008 09:10:06 UTC