W3C home > Mailing lists > Public > public-bpwg@w3.org > April 2008

[minutes] Thursday 17 April 2008 Teleconf

From: Francois Daoust <fd@w3.org>
Date: Thu, 17 Apr 2008 17:48:58 +0200
Message-ID: <4807716A.7040300@w3.org>
To: public-bpwg@w3.org

Hi guys,

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

... and pasted as text below.

Main resolutions:
- decisions were taken on the remaining mobileOK issues.
- resolution was made to (once changes are made) publish mobileOK Tests 
as Last Call again, to wait for 3 weeks, and then, provided Candidate 
Recommendation exit criteria are met, to jump directly to Proposed 
Recommendation
- there will be a call next week, as usual

Francois.



17 Apr 2008

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/public-bpwg/2008Apr/0054.html

    See also: [3]IRC log

       [3] http://www.w3.org/2008/04/17-bpwg-irc

Attendees

    Present
           francois, Dom, drooks, jeffs, jo, adam, Sean_Owen, Magnus,
           hgerlach, SeanP, miguel, manrique, achuter, DKA

    Regrets
           PhilA, EdM, nacho, shah, kemp, MartinJ, Bryan, Yeliz, rob

    Chair
           Jo

    Scribe
           francois

Contents

      * [4]Topics
          1. [5]Content Transformation
          2. [6]mobileOK issues
          3. [7]BP2
          4. [8]Korean TF
          5. [9]mobileOK Pro TF
          6. [10]Next week's call
          7. [11]Back to BP2
      * [12]Summary of Action Items
      _________________________________________________________

    <jo> [13]Agenda

      [13] http://lists.w3.org/Archives/Public/public-bpwg/2008Apr/0054.html

Content Transformation

    <inserted> ScribeNick: jo

    FD: CT Document was published in FPWD earlier this week

    <francois> [14]CT guidelines FPWD

      [14] http://www.w3.org/TR/ct-guidelines/

    FD: Have received one comment so far, and we are continuing to work
    and to publish a document in Last Call before or at the F2F in June

    <dom> ScribeNick: francois

    jo: questions?
    ... no question, fine.
    ... We discussed last week about having a workshop-like event for CT
    ... The GSMA has kindly offered to host such an event, so we now
    need to setup a date for that to happen
    ... I'll work with francois, dan, dom, and marie-claire on that
    ... The likely date: the week immediately after the F2F meeting
    ... the general idea being for people coming from far away to stay
    over the weekend and attend the event as well
    ... 23 June 2008 or 24 June 2008 are the likely dates for the
    moment.
    ... Any comment on the date?
    ... Is it convenient?

    <SeanP> I'm from N.A., I think it will be OK, I'll check on it
    however.

    jo: OK, so we'll consider this was an excellent idea we came up with
    ;-)
    ... We should get back with news within a week or less hopefully.

mobileOK issues

    jo: dom, would you like to introduce the topic?

    <jo> [15]Dom on mobileOK

      [15] http://lists.w3.org/Archives/Public/public-bpwg/2008Apr/0047.html

    dom: basically 4 open issues on mobileOK Basic

    <Seungyun> hi this seungyun from Korea

    dom: and none of them are waiting for new inputs, so we need to
    decide for resolutions on these issues
    ... For each of them, I proposed 2-3 possible resolutions

    <Seungyun> sorry I am only available with IRC

    dom: First issue: ISSUE-230: OBJECTS_AND_SCRIPTS
    ... and the problem of multiple objects children

    <jo> ISSUE-230?

    <trackbot-ng> ISSUE-230 -- OBJECTS_AND_SCRIPTS needs to address
    <object> with multiple children -- OPEN

    <trackbot-ng>
    [16]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/230

      [16] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/230

    dom: Currently, we assume that the nesting can only be done as one
    object inside another one, whereas it can be done recursively.
    ... That's not pretty usual, but it may
    ... Few options on the table:

    1. ignore this, we'll fix it later

    2. new algorithm suggested by Jo and Sean

    scribe: I think it would suit us fine

    <jo> the proposed algorithm:

    <jo> For each object element that has no object element ancestor

    <jo> Request the object (ingoring the type attribute)

    <jo> Apply the Object Processing Rule

    <jo> Object Processing Rule

    <jo> If the content type of the retrieved object is not image/jpeg
    or image/gif

    <jo> If it is empty, warn

    scribe: 3. remove object parsing

    <jo> If it consists only of white space, FAIL

    <jo> For each of its descendant object elements that is not a
    descendant of another descendant object element, apply the object
    processing rule

    dom: my proposed resolution would be to use the new algorithm

    s/[scribe says to take a look at Dom's email for more details on the
    algorithm]//

    <jo> PROPOSED RESOLUTION: Adopt algorithm above as Resolution to
    ISSUE-230

    jo: comments on that?

    <jo> +1

    <dom> +1

    <Kai> +1

    <adam> +1

    RESOLUTION: Adopt algorithm above as Resolution to ISSUE-230

    Second issue: ISSUE-231: MINIMIZE should take into account
    whitespace in CSS

    <jo> ISSUE-231?

    <trackbot-ng> ISSUE-231 -- MINIMIZE should take into account
    whitespace in CSS -- OPEN

    <trackbot-ng>
    [17]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/231

      [17] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/231

    dom: whitespace is currently not counted in CSS, only in the markup,
    so we could extend it.
    ... actually, that was already implemented in the checker
    ... 2 possibilities:
    ... 1. we include CSS white space in the test
    ... 2. we leave that for a next version of mobileOK basic
    ... I suggest to wait for next version. It's not a broken test, we
    should keep things simple.

    <jo> PROPOSED RESOLUTION: Leave mobileOK as is and look at CSS
    redundant whitespace in a new version of mobileOK

    <Kai> I had written a technique on that, which could be used by the
    checker

    jo: kai, before you comment, the checker already has some dormant
    code that is not executed, so it's less about changing the code, but
    rather the document

    kai: ok, understood

    jo: any other comment?
    ... ok.

    RESOLUTION: Leave mobileOK as is and look at CSS redundant
    whitespace in a new version of mobileOK

    <jo> +1

    <dom> +1

    <Kai> +1

    <jeffs> +1

    <miguel> +1

    <adam> +1

    <jo> ISSUE-234?

    <trackbot-ng> ISSUE-234 -- PAGE_SIZE_LIMIT Should Objects Tasted
    count towards the overall page weight -- OPEN

    <trackbot-ng>
    [18]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/234

      [18] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/234

    Third issue: ISSUE-234 Counting the bytes that travel through the
    network in case an object is not supported by the browser

    dom: the most controversial one
    ... jo suggested we should actually count that as part of the total
    page size, given the 20K limit test.
    ... we did a bit of experimentation to see in which cases a browser
    downloads objects it doesn't support

    <Seungyun> agreed

    dom: 2 options again:
    ... 1. we add that algorithm in our calculation of PAGE_SIZE_LIMIT
    ... 2. we keep it for the next version of mobileOK basic
    ... I personally prefer option 2, but I know there were some
    discussion on that

    jo: I fear that this might end up labelling mobileOK pages that
    actually downloads 10s and 100s of Kb of code
    ... I would prefer that we count objects that don't set a type
    attribute

    <jo> PROPOSED RESOLUTION: Add the size of ojects referenced without
    a type attribute indicating what type they are

    <jeffs> srowen: /ojects/objects

    dom: [convinced by jo's crying]

    <jo> +1

    <dom> +1

    <jeffs> +1

    <Seungyun> +1

    RESOLUTION: Add the size of objects referenced without a type
    attribute indicating what type they are

    <jo> ISSUE-240?

    <trackbot-ng> ISSUE-240 -- Remove requirement of validity to
    self-declared DTD -- OPEN

    <trackbot-ng>
    [19]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/240

      [19] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/240

    Fourth issue: ISSUE-240 validation to the declared DTD

    dom: currently, mobileOK Basic says you have to be both valid to the
    declared DTD and the XHTML Basic 1.1 or MP1.2 DTD
    ... the problem is in terms of implementation, it's a pain to do
    SGML-validation for HTML 4.x and ancestors docs

    <jeffs> IMHO validity testing should be there

    dom: If the declared DTD is external, that means the checker has to
    download the DTD from an unknown server
    ... So I think we should remove the validation to the declared DTD,
    while still keeping the XHTML Basic1.1 or MP1.2 DTD
    ... Second option is to validate only on well-known DTDs (OMA, W3C)
    ... Little consensus for the time being.

    <jeffs> IMHO option 2 is okay

    <jeffs> zakim unmute me

    jo: even if you are valid to your declared doctype, then you won't
    be mobileOK if you're not also valid to XHTML Basic 1.1 or MP1.2
    ... I don't quite see the point of validation agains well-known
    DTDs, because that's not coherent.
    ... for the sake of simplicity, my preference would be that we drop
    the test on the declared DTD

    jeffs: I can see your argument
    ... The only thing I'm concerned is the future

    <jeffs> can live fine with "validate only on well-known DTDs (OMA,
    W3C)"

    <jo> PROPOSED RESOLUTION: Drop validation against declared DOCTYPE
    as it does not represent sufficient added value compared with the
    complications it introduces

    <jo> +1

    <dom> +1

    <jeffs> -1

    <Kai> +1

    srowen: no further comment, I agree.

    <jeffs> okay

    <jeffs> +1

    <jeffs> sorry

    RESOLUTION: Drop validation against declared DOCTYPE as it does not
    represent sufficient added value compared with the complications it
    introduces

    dom: that's it. But we need to discuss the implications in terms of
    W3C process for the doc.
    ... The changes could be substantive enough, IMO, to require another
    Last Call draft
    ... ISSUE-230: it's just a reword, so we'd be safe on that one
    ... ISSUE-234 (counting tasted objects) and ISSUE-240 (validation
    against DTD): substantive changes because you could be mobileOK
    before and not anymore (well, for ISSUE-234 only actually)

    <Zakim> Kai, you wanted to ask about potential changes resulting
    from mobileOK Pro work

    dom: Given that this would be the 4th Last Call, so the plan could
    be that we go to Last Call, wait for 3 weeks, and then jump directly
    to Proposed Recommendation

    Kai: I wanted to know if we should address potential changes that
    work on mobileOK Pro may bring

    srowen: Kai, I thought you were talking about Best Practices in your
    email

    kai: yes, indeed.

    jo: Best Practices should soon be cleared to go to Rec, since XHTML
    Basic is likely to move soon to PR
    ... so mobileOK Basic Test could be cleared to go to PR shortly
    after that.

    <dom> [just a reminder that to go to PR we still need to complete
    our CR exit criteria]

    jo: there's a possibility that both BP1 and mobileOK Basic be Rec
    before June's F2F

    dom: yes... that would be possible

    jo: I don't think we should do that, kai.

    kai: that's fine, I just wanted to bring that point.

    jo: in that case, I would acknowledge your point kai, but propose we
    don't do anything for that

    <dom> [the publications moratorium ends on April 28; so we should
    try to have mobileOK basic ready to go to LC by then]

    <jo> PROPOSED RESOLUTION: mobileOK Basic to be changed in the three
    ways noted above, to re-enter last call for the minimum period, and
    then to seek transition to PR as soon as possible given CR exit
    criteria met

    <jo> +1

    <jeffs> +1

    <dom> +1

    <Kai> +1

    <achuter> +1

    RESOLUTION: mobileOK Basic to be changed in the three ways noted
    above, to re-enter last call for the minimum period, and then to
    seek transition to PR as soon as possible given CR exit criteria met

    <jo> ACTION: Jo to enact changes to mobileOK as noted above
    [recorded in
    [20]http://www.w3.org/2008/04/17-bpwg-minutes.html#action01]

    <trackbot-ng> Created ACTION-736 - Enact changes to mobileOK as
    noted above [on Jo Rabin - due 2008-04-24].

BP2

    jo: lots of things to talk about BP2, but I'm not sure we'll be able
    to make much progress in Bryan's absence.
    ... Let's put the comments on one side.
    ... and discuss two issues that I raised yesterday
    ... But before we do that, let's talk about the Korean TF

Korean TF

    <Seungyun> thanks

    -> [21]http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/
    Korean TF home page

      [21] http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/

    <jo> [francois just giving perspective on set up of home page etc.]

    <Seungyun> I sent a email to all of you with updated proposal link
    --> [22]http://docs.google.com/Doc?id=ddkw3489_18gg7zjk57

      [22] http://docs.google.com/Doc?id=ddkw3489_18gg7zjk57

    public-bpwg-korean@w3.org

    -> [23]http://lists.w3.org/Archives/Public/public-bpwg-korean/
    archives of the Korean mailing-list

      [23] http://lists.w3.org/Archives/Public/public-bpwg-korean/

    <jo> Seungyun, we'll review your note separately, do you want to
    make some comments via IRC on current status?

    <Seungyun> sure

    <Seungyun> we have disscussed about TF operation with mobile web 2.0
    forum members yesterday.

    <Seungyun> so you can see the results from
    [24]http://docs.google.com/Doc?id=ddkw3489_18gg7zjk57

      [24] http://docs.google.com/Doc?id=ddkw3489_18gg7zjk57

    <DKA> +1

    <jo> OK, thanks, Seungyun,

    <DKA> (just catching up with previous resolutions -- sorry)

    <Seungyun> please review them and comment me

    <jo> OK Seungyun, we'll aim to comment and close this issue next
    week

    <jo> thanks for the update

    <Seungyun> ok thanks

mobileOK Pro TF

    kai: lately, not much had happened. We've had had no feedback, so
    nothing is happening.

    jo: ok. So what would you suggest to stimulate progress on this
    subject?
    ... ok, I think we should aim for resolving for publication as FPWD
    within 2 weeks

    dom: kai, you said there was no feedback, but from my understanding,
    you added new tests recently. Is there a new draft available?

    kai: yes and no. I was willing to wait until we have all tests
    finished.

    dom: I haven't sent feedback on current version as I sent feedback
    on previous version and am waiting for the next one.

    kai: your feedback was the only one and was taken into account

    <dom> [25]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/716

      [25] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/716

    kai: I think we have fairly improved the reliability of the tests

    dom: I think we should have a clear picture of this before moving to
    FPWD

    kai: suggestion on the best way to proceed?
    ... should I post the doc as it is? should I wait until it is
    finished?

    dom: my concern was more on how we want to position mobileOK Pro
    compared to mobileOK Basic, what public are we targetting

    kai: I understood the discussion would be headed by having a
    document at hand

    <jo> ACTION-716?

    <trackbot-ng> ACTION-716 -- Phil Archer to summarise discussion on
    Pro subjectivity and to get ball rolling for a PROPOSED RESOLUTION
    on the subject -- due 2008-03-20 -- OPEN

    <trackbot-ng>
    [26]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/716

      [26] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/716

    kai: so the action is there, but the issue needs to be raised?

    dom: yes, and more than raised, we need to discuss it, and find a
    consensus on that

    jo: the real test of subjectivity is probably not what the WG
    thinks, but what the community thinks

    <dom> [re assigning ACTION-716 to Kai]

    <srowen> (I apologize, I need to drop off early today)

    kai: if it's ok that the doc is not completely finished, then I'll
    update a fresh version of the doc

    <Kai> i will

    <dom> [I'll be away the next 2 weeks]

Next week's call

    Jo: btw, how many people will be in Beijing?

    <achuter> I won't

    <jo> PROPOSOED RESOLUTION: Hold a call next week, as only a few
    people will be in Beijing

    <jo> +1

    <dom> [note that the following Thursdays after next May 1st and 8
    may be closed in a few European countries]

    +1

    <jeffs> +1

    <Seungyun> I will be there :)

    <miguel> +1

    RESOLUTION: Hold a call next week, as only a few people will be in
    Beijing

Back to BP2

    jo: 2 issues I raised based on discussions on the mailing-list

    <jo> ISSUE-245

    <dom> ISSUE-245?

    <trackbot-ng> ISSUE-245 -- ADC, A Wooden Stake and Some Garlic
    Needed -- OPEN

    <trackbot-ng>
    [27]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/245

      [27] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/245

    jo: kai, as a proponent of the idea of the ADC, would you like to
    speak in favor of it?
    ... as I have explained, I'm not much in favor of defining the ADC,
    would be impractical

    kai: If I transpose the DDC into the ADC, it gives the public a mean
    to shoot for
    ... for people that are not inclined to use content transformation,
    then the ADC gives a delivery context that would work on most
    devices
    ... We're answering the call of the public for something more
    modern.

    jo: other comments?

    kai: I'm amazed that nobody has anything to say about that.

    adam: I'm wondering if there's something that would not be called
    ADC that could be used in the doc.
    ... in BP1, we said "don't rely on this"

    <jeffs> the more we can tell people concrete things they can
    actually do to exploit dev caps, the better

    adam: in BP2, it's more "to rely on this, do that"

    jo: provided we can name the capabilities and features of a device,
    and how to tell if the capabilities are there or not, then we get a
    clearer doc and useful document
    ... I strongly support the idea that each BP we advocate may not
    apply to all devices

    <jeffs> how to test for caps, how to exploit what you find... expect
    to find this in a document entitled "Best Practices"

    jo: BP2 as an extension to BP1 on "exploit device capabilities"

    <dom> +1 to Jo's approach

    jo: Agreeing on an ADC would take too much time and market goes fast
    as Adam points out
    ... and I think that's just not needed.

    <Zakim> Kai, you wanted to ask what it would mean then to be
    mobileOK

    kai: what form would mobileOK take with BP2?

    jo: mobileOK Basic is simply an expression of how the content would
    display on a device with minimal capabilities
    ... I don't have a mobileOK equivalent to BP2 on my agenda although
    that certainly needs to be discussed

    kai: if we expect people to go to a certain point, then we should
    give them a goal to shoot for.

    jo: that's not what BP2 are about. It's about saying: "get your nose
    up!"
    ... It's perfectly ok to have the basic thing, that was needed.
    ... BP2 need to be practical enough to be implementable.

    <jeffs> IMHO: mobileOK is minimum, not *best* practices...

    <jeffs> that is why we need both

    kai: the point I'm missing is why not providing a set of values that
    people should program against?
    ... whether we have an ADC or not, if the ADC gets outdated, then
    the capabilities would be outdated, and so would be the doc
    ... I think we're not giving the community something useful

    jo: DDC is representative of the minimum capabilities to render
    pages, it's not linked to any point in time.

    <dom> [related to device capabilities detection, screenshots of the
    recently released Web Compatibility Test for Mobile Browsers
    [28]http://www.w3.org/2008/04/wctmb/ ]

      [28] http://www.w3.org/2008/04/wctmb/

    jo: It's all about Web experience: the minimum width, ...

    <hgerlach> sorry, I have to leave - bye

    <jo> PROPOSED RESOLUTION: We continue not to define an ADC but will
    treat each of the capabilities in its own right in BP2

    <Kai> -1

    <adam> +1

    <jo> +1

    <jeffs> +1

    dom: I think Jo's approach is the right one: for each BP, what
    properties/capabilities are associated with it.

    <DKA> +1

    dom: I guess we can't resolve right now as there doesn't seem to be
    a consensus here.
    ... kai, you probably should continue and make your points about how
    ADC will help the community at large on the mailing-list

    <jo> ACTION: Kai to take the discussion forward on ISSUE-245
    [recorded in
    [29]http://www.w3.org/2008/04/17-bpwg-minutes.html#action02]

    <trackbot-ng> Created ACTION-737 - Take the discussion forward on
    ISSUE-245 [on Kai Scheppe - due 2008-04-24].

    <jeffs> I ust go

    jo: ok, thanks everybody, we'll resume on that next week.

    <jeffs> bye

    [adjourned]

    <Seungyun> bye all

    <miguel> bye

Summary of Action Items

    [NEW] ACTION: Jo to enact changes to mobileOK as noted above
    [recorded in
    [30]http://www.w3.org/2008/04/17-bpwg-minutes.html#action01]
    [NEW] ACTION: Kai to take the discussion forward on ISSUE-245
    [recorded in
    [31]http://www.w3.org/2008/04/17-bpwg-minutes.html#action02]

    [End of minutes]
Received on Thursday, 17 April 2008 15:49:28 UTC

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