- From: Francois Daoust <fd@w3.org>
- Date: Thu, 17 Apr 2008 17:48:58 +0200
- 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