See also: IRC log
<jo> Agenda
<inserted> ScribeNick: jo
FD: CT Document was published in FPWD earlier this week
<francois> CT guidelines FPWD
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.
jo: dom, would you like to introduce the topic?
<jo> Dom on mobileOK
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> 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> 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> 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> 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 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].
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
<Seungyun> thanks
-> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/ Korean TF home page
<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 --> http://docs.google.com/Doc?id=ddkw3489_18gg7zjk57
public-bpwg-korean@w3.org
-> http://lists.w3.org/Archives/Public/public-bpwg-korean/ archives of the Korean mailing-list
<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 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
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> 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> 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]
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
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> 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 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 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