Mobile Web Best Practices Working Group F2F Day 2

6 Nov 2007

See also: minutes Day 1 - IRC log


Aaron_Kemp, Abel, AnnBasetti, Arun, Bruno, Bryan, Dave_Raggett, Drew_Major, EdM, Francois, GeoffFreed, Ileana, JonFerraiolo, Jonathan_Jeon, Jose, Kai, KlausBirkenbihl, Lynne_Rosenthal, Mark_Bakies, MikeSmith, PhilA, Rhys_Lewis, Rob_Finean, Rodrigo, SeanP, Sean_Owen, Serge, Shah, Soon-Ho_Lee, Timo, GarlandPhillips, PhilippHoschka
Dan, Jo
Phil, edm, MikeSmith, Aaron, Bryan




<jo> Date: 6 Nov 2007

<PhilA> DKA: Begins meeting, suggests tour de table...

<PhilA> Dan and Jo sort out the logistics, scribes, agendas and so on

<PhilA> DKA: How many people here in CT TF?

<PhilA> four hands

<PhilA> scribeNick: PhilA

<scribe> scribe: Phil

There are 4 CT TF members present

<edm2z> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/Overview.html

Rhys: CT TF has 2 deliverables as decided in London f2f
... 1 - to define problem statement (limited scope)
... guidelines document to help people avoid the pitfalls

<DKA> http://www.w3.org/TR/2007/WD-ct-landscape-20071025/

Rhys: Problem doc is now in TR space and will become a WG Note

<edm2z> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/ProblemStatement/071008

Rhys: Where there are multiple players in delivery channel between server and client
... Is trying to work out how they can signal to each other as they don't cuase errors in what each other does
... eg - material on origin server is already adapted for the end device
... Found recent situations where intervening transforming proxy has carried out inappropriate transformations
... purpose of TF is to work out what can flow between participants to avoid that happening
... Focussed on using existing W3C tech to do it
... Therefore we're producing a guidelines doc, not a normative Rec

Bryan: Do no harm, not do it better?

Rhys: Yes
... Who's read the doc?

Many hands go up

Rhys: Notes Bryan's comments
... we have a skeleton guidelines doc and we're working on filling in the blanks
... Jo has recently done some work on suitable signalling
... We're not just talking about proxies and servers - clients have a role to play in user preferences
... User should have choice in whether they see transformed or raw content
... Invites Jo to take us through his recent post

<edm2z> http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0057.html

<jo> Action Relating to Possible Techniques

DKA: A question in the meantime - a lot of this was kicked off by the controversy about content adaptation proxies not sending the UA string through
... Are we going to give content providers the guidance they need or will it be so elaborate that it won't help?

Rhys: It wouldn't be productive if we couldn't find a relatively simple solution
... The feeling I get is that there is a fighting chance of coming up with some helpful guidance

DKA: My litmus test - I'd like to be able to talk to developers without being booed down as happens now...
... More seriously, you need not worry - here is what we, the industry, are doing to fix this problem

Rhys: The idea that we'll provide something that can please most of the people most of the time is our aim

DKA: The message is - 'adapt your content' - that's the way forward for the mobile web?
... The best outcome from this doc is that it fits into that univese

Rhys: We're articulating how transforming proxies fit into that eco system

Bryan: The message that developers get - we need to educate them to the nature of the options that they have
... Either very specific to mobile, or adpating to mobile, or not caring and leaving it up to adaptation
... We need to educate them what different headers can do and why they should use them - and then move on

Jo: There are various options. One very narrow using HTTP and the other related to the scope of the guidelines doc

Slight hiatus while Jo and Dan do a jig for us all

Jo: This is a very dense debate. Bryan in particular, made some very useful comments...

<Rhys> http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0041.html

<jo> http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0057.html

Jo: The question is - how far do you go?
... Are we trying to write a doc that tells people how not to do any harm, or are we going to guide people through the whole chain?
... The consensus seems to be that we're not going all the way to the detail extreme
... Complicated by some browsers that act as proxies :-)
... A sequence of proxies may be treated as a unit of proxy capability
... The issue at hand is - are we going to deliver the desktop presentation or the specifically mobile-crafted version and where is that latter version created, if it is created
... Bearing in mind that the WebKit [which both the Nokia S60 and Apple Safari and iPhone browsers use as their backend] can do a lot, how does the server know what the browsser is able to do?
... Given that the browser is not able to provide the mobile experiecne on its own and the server may be able to, how do we get the mix right?
... There are 64 permutations I reckon
... Each of the 3 components can do one of 2 types of transformation
... At the markup level they can clean up markup, compress images etc. This seems different from re-formatting of content, including or excluding some etc.

Rhys: There are lots of options for how the differnt entities can react to each other
... The complete set of options is large
... e.g. is the server can or can't negotiate to come up with a mobile version etc
... we should minimise the number of things we address in the initial doc as we have very limited time for the TF
... Then again, if we miss out key use cases, then we'll be skipping too lightly

Bryan: I can add a summary of the conversation...
... Let me try and get some yes/no in/out statements
... Whether to offer choice to user? Yes
... How to offer chocie? No
... Behaving as requested? Yes
... Protecting from harm? Yes
... Avoid non-web app harm? Yes

Rhys: Is this in an e-mail?

Bryan: yes, but this is a summary
... Objectives - usability and interop - yes
... Optimisation, personalisation, content control - grey areas
... If it becomes a policy point then I'd say No

Jo: Good summary of the kinds of things we've been pondering - broadly I agree
... Might be worth working through some use cases
... Case 1 - the classic case that the server only has a deskptop only presentation and the server only has desktop
... In this case it is possible that the server's presentation may be universal and so will lay out properly in either
... In general that's not the case
... A personal feeling - proxies should do what they do reluctantly, more in sorrow than anger.

<Zakim> achuter, you wanted to mention mobileOK complication

<Zakim> Kai, you wanted to ask about layout independent presentation

Kai: I noticed a potential use case missing - a layout-neutral presentation. Maybe an XML instance provides the data and the layout is separate

Jo: Yes, but I think what we're trying to do, erm, I don't think that's a use case that we want to consider at the moment
... Stylesheet application etc. But that's not what we're talking about within our scope with limited timeline
... Case 2 - server has both mobile and desktop presentation available
... Assuming that the content provider's wishes are honoured, the user will get the mobile presentation - with the caveat that there should be a way for the user to specify the desktop presentationb
... If both content provider and user both express preferences and they're different, who wins?
... CP may be able to say I don't care what you want, I'm sending you this

ack: sea

seanP: Usually the user preference will prevail
... There's some discussion about whether the mobile page is better than the transformed desktop page, but sometimes the desktop page may have more content that the user actually wants
... If the mobile version is a summary, there are cases where the suer wants the full content, irrespective of the fact it looks awful...

ack: sean

Rhys: Where we do have a user preference, it's pretty straightforward - we should honour the user's preference
... Where the user doesn't have the ability doesn't have the choice then the author gets the next shout
... (i.e. if you don't know what the user wants)

<Zakim> Kai, you wanted to speak of prior experiences with providing desktop content for mobile users

Kai: We've tried for a long time to take desktop content and make it work for mobile - and it doesn't work
... User choice would be good - and we should store that choice for next time
... On an editorial level, there's far more info on a desktop page than a typical mobile page. We've tried to create condensed versions automagically and it doesn't work - you have to create 2 separate instances

<Rhys> acl dka

DKA: We're straying into policy
... Shouldn't we be transparent for all parties so everyone knows what's going on?
... If you have enough info so the browser, proxy, server and user know what's available, then you can use business rules to work out what to do

Rhys: Interesting. That speaks to the guidelines scope
... It should probably say that if you don't know the user preferences you should use the adapted conte,t not transcoded contnet. Then you might expose that policy as a user-configurable option - but that sounds like a level up from where we're at

Jo: I agree
... I don't thinkwe should specify policy, but we should illuminate that there are policy choices to be made
... ANd we should provide a vocabulary to enact those policies
... e.g. we might say 'in general, CP, it is bad practice to be hard-nosed about re-formatting, especially in terms of removal of bad mark-up etc.
... However, I don't think we should remove the option from the CP to say 'I know what I'm doing'.
... Even if they don't, that's probably not the point. It's their content and ultimately, that's the war
... SO we can summariese the policy choices, here's the vocab to express those policies, and we think you should use option x and leave it at that
... If the operator of the proxy thinks that untransformed content will cuase a problem then the user should be warned

Bryan: As Rhys said, we're trying to solve the problems, not opening up new ones. The key thing is how to express the desire?
... There has to be some understanding of intent
... We need to figure out how to signal intent in a dynamic way

Rhys: Yes - we need to work out techniques for that and that should work in the absence of intent as well

SeanP: The proposed 'do not transform' header does that, but I think there should be another like 'do not transform unless you know you can do a better job' or whatever

Sean: There's a limited number of options but it's more than binary

<Zakim> Kai, you wanted to mention the conflict of user choice vs. provider choice. Both needs to be possible, but may not be easy to do simultaneously. Give providers tools to do what

Kai: Users may well not understand the choices...
... There's a need to give CPs the tools to do it right. Whether they use them or not is an open question

<edm2z> scribe: edm

<edm2z> scribenick: edm2z

jo: whose preferences should take priority is not always a straightforward question ...

<jo> [note to self - bookmark the "roaming issue"]

rhys: operator and user position may be influenced by cost issues

DKA: e.g., user may be happy to use desktop version with fast data service, mobile otherwise ...

SeanP: mobile browsers may be unable to deal with some types of content (e.g., Flash), but proxies could adapt these...

rhys: we do not want to encourage using separate URIs for accessing desktop vs. mobile friendly content

<jo> [kai sometimes neither the cp or the user knows what hey want, are we going to provide some guidelines]

rhys: everyboby should now have a good idea of the anticipated scope of CT guidelines

<jo> Possible Techniques for signalling capability/awareness or preference

PhilA: content personalization is out-of-scope, but could it be considered to be a useful extension of CT ?

Bryan: we should narrow the primary focus of CT to interoperability and usability

rhys: initial scope is very narrow - to solve a particluar problem - but we do not want to limit potential future functionality of adaptation proxies

jo: let's start discussing specific techniques - see http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0035.html
... refers to the list in http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0023.html
... [continues to review the list above - in the spirit of HTTP headerspotting??]

rhys: these techniques may not be universally usable - can a transforming proxy be informed by the UA header what to do ?

PhilA: huge amount of info may have to be crammed into a couple of headers - should we focus on what info would be most useful?
... other W3C groups are already working on the issue of how to communicate certain info ...

Bryan: we should come up with a simplest possible solution to the problem - not necessarily overload the existing semantics

srowen: simple is best - we should recommend not changing original UA

<kemp> [actually sean is advocating _changing_ the user agent to the proxy's useragent]

<srowen> (srowen paraphrases himself: proxy should not do anything but say "I am a proxy" in its User-Agent. Therefore don't recommend anything but what proxies are doing today for the request. No need to overload, stretch, or invent mechanisms. 20, 21, and 23 are existing simple way to communicate "I may adapt content". Proxy merely redirects to origin server and gets out of the way. So 20, 21, 23 seem to solve it all nicely to me.)

rhys: we try to overloading existing HTTP semantics - but educating about its proper use makes sense

jo: we are not chartered to create new technology - should leverage what exists, bt also point out any constraints we may be running into

<MikeSmith> Scribenick: MikeSmith

Rhys: We just completed discussion on what role and additional User-Agent header might play.

Add the real user agent as part of the massaged user agent string

kemp: I think putting it in the User-Agent is probably a bad idea ...
... I'd be more inclined to change the User-Agent to say "Inspect this other header"

Tasting of content with original header.

jo: question of idempotency and other questions ...
... the other advantage of this is that it addresses the concerns of the those who don't want to change their current [habits/expectations with regard to headers]

Use an Expect header

jo: this is a little rococo ...
... certainly fits in with the existing rules of HTTP

Option 7: Embed original HTTP headers as part of the multipart MIME-encoded elaboration of the request as a message/http part

Rhys: Are we aware of any examples of where passing other headers through causes any problems?

jo: The are two separate cases ...

Rhys: question is which headers are actually expected and can we find a way to pass them through.

Point 8. Extend the interpretation of host or nickname field in the Via header

jo: HTTP says you can drop comments from the Via header ...

<Rhys> The point was that there are other headers that an origin server might use. An alternative mechanism to the multipart mime approach is simply not to replace those other headers. The decision on whether or not to repace other headers is the same one as whether or not to replace the user agent header

jo: so information can be lost and we can't rely on it being preserved
... Question is, are these comment parts every actually dropped [in practice]

Alternative is to use an X-Via header

scribe: which is defined as a copy of the Via header but with comments always preserved

so all the above was a discussion related of Request [stuff]

now on discussion of Response stuff


jo: As a content provider, you may be aware of potential markup cases that could cause problems with certain handsets but you don't fix those because you choose to leave it up to CT proxies or something to deal with instead.

Rhys: CT proxies are providing value by solving those kinds of problems.
... In this TF we are talking about CT proxies that transform the current Web

Bryan: You can extend Cache-Control to more than just No-Transform

Point 22: Taste the content

Point 23: Look for link elements

kemp: The "look for LINK elements" practice is out there and widely used ...
... so we do need to acknowledge it

SeanP: back to 300 response ...
... question: Is it used already with some default body that we would end up stomping on?

Bryan: Are we chartered to create new uses, new headers?

Rhys: My view is no, we are not.
... we might conclude that we can't do this just by producing a guidelines document ...
... but there is at least a fighting chance that some combination of them will in fact do what we need ...

<Rhys> ack 300

DKA: If we do decide to do something with 300, we need to be very sure to [do thorough research on it]
... get some findings

<PhilA> new methods, headers, or extension mechanisms, but may introduce new

<PhilA> protocol elements if necessary as part of revising existing

<PhilA> functionality which has proven to be problematic"

jo: whatever we do come up with will require a thorough period of testing ...

<Zakim> PhilA, you wanted to quote from HTTP WG charter: "The WG is not tasked with producing

Rhys: Anybody have anything to add to the list?

DKA: We are focusing on the server and network side ...
... but so far, not address the case of advanced browsers ...
... being able to communicate [their advanced-ness]

kemp: I think some of these do address the case of allowing a browser to communicate its capabilities

jo: I think there are some things outside of what Aaron already mentioned ...
... potential use or misuse of Pragma, for example

Rhys: A mechanism for transmitting the notion that the user has made a choice ...
... about what he or she wants to see

DKA: What I was talking about was more on the guidelines side of things
... Also, I'm worried about this "tasting" thing ...

[DKA mentions problem of someone putting an item into shopping cart twice]

Bryan: We do need to address how [some of this has potential] to break Web applications.

<scribe> Scribe: MikeSmith

[discussion about communication with IETF]

DKA: Important that we are not trying to invent an adaptation solution in this group

Rhys: I think we need to be careful to use phrases like "not aware" ...
... we have other cases where [because of old server software or whatever] we need for the chain to be robust ...
... which is where things like tasting come into play

SeanP: About tasting/differentiating ...
... if we are talking about use of existing stuff like the LINK element [then OK]

Rhys: We have added a good number of topics which are now going to be the subject of further work ...
... we have achieved a lot today, as far as what we can manage to get done at this f2f

DKA: What we are seeing in the field now ...
... is that people are already using a new header
... and we can perhaps give guidance on what the actual nomenclature of the header should be

srowen: My personal view is that we do not need a new header
... would rather tell people to use X-Device-User-Agent ...
... or whatever is in use ...

DKA: Big question is: Which one do we suggest they use?

SeanP: I obviously don't have a problem with use an X-User-Agent header
... but I agree there is a problem with several different headers [being used for the same purpose in the wild today]

<Zakim> rob, you wanted to support Rhys and Sean - ie let's see

RobFinean: I just want to support what Rhys has been saying ...
... we need to look [at the big picture first]

<srowen> (srowen paraphrases himself again: let's not wait to codify a brand new official header. takes too long anyway. I don't want to glorify this mechanism anyway. Just pick a commonly used x- header for this purpose and go forward)

SeanP: The fact that these solutions already exist ...
... one thing you might conclude is that the way it's already being done [is in fact the best way]

PhilA: There is potential for wanting to say quite complex things ...
... there is a lot of potential complexity there ...
... the HTTP headers can give you only basic information ...
... There is a lot more richness to this than can be put into HTTP headers ...

jo: Is there any need to [put this information into HTTP headers etc.] if it is possible for the information to be obtained from using something like a Device Description repository ...

Rhys: Value in transmitting user preferences ...

jo: So we are going to try to simplify the use cases to the set of use cases that are the leading ones [in terms of actual current practice]

Rhys: I think you all have just agreed to not be surprised when you see our first working draft [laugh]

[we meet back at 13:15 to talk again about Charter II]


<jo> scribenick: kemp

<scribe> scribenick: kemp

<MikeSmith> Scribe: Aaron

Workshop on Mobile Ajax

DKA: [introducing our ajax visitor and referencing our proposed resolution yesterday to make two documents]

<MikeSmith> http://www.w3.org/2007/06/mobile-ajax/

<edm> http://www.w3.org/2007/06/mobile-ajax/

<MikeSmith> http://www.w3.org/2007/06/mobile-ajax/report.html

john: ... talking about the origin of ajax and the OpenAjax alliance...
... alliance includes mobile oriented companies, but was focusing on the desktop. launched the mobile taskforce with rhys as chair

<jo> [speaker is Jon Ferraiolo of IBM/OPen Ajax Alliance]

JonF: a workshop was held... wrapup findings included the belief that there will (at some point) be a common Ajax platform between desktop/mobile
... many vendors are now using webkit or other high end browsers for modern phones.

DKA: (at the event) i remarked that we are seeing convergence between desktop and mobile, so what we'll end up with is the web, on mobile, instead of the mobile web

JonF: from a developer point of view, we're seeing the creation of javascript libraries that web content developers use instead of writing HTML or JavaScript directly.
... however these libraries are not yet there for mobile -- mobile is the next big thing on their list (especially with the iphone/nokia webkit browsers)
... back to OpenAjax -- the overall goal is how can we help the industry advance so that these technologies will deliver rich applications on mobile devices.
... in general, the industry seems to be doing well on its own -- we primarily want to focus on education
... so we want to issue whitepapers, talking about the current state of the industry and the standard techniques, but not get into details about how to make a good application
... another group (the best practices) would develop a set of best practices based on the whitepapers from OpenAjax
... (discussion about desktop/mobile sharing of libraries/runtimes)

skarim: some issues may still arise, because the execution environment on the mobile is more limited than a desktop (eg processor speed, memory, bandwidth)

Bryan: was there any presumption about the runtime environment and how it would compare to the desktop? i think the presumption is that it would be inside the browser sandbox

JonF: yes there was a focus on the browser sandbox, but we talked about widget frameworks so that ajax applications would be installable as mini applications

<Zakim> skarim, you wanted to comment about browser sandbox vs. web runtime

DKA: we talked about this a bit yesterday when talking about the scope of BP2 -- for the purposes of BP2, I think the practices can be applied in either case

skarim: there is a distinct difference between browser sandboxes and widget shells

DKA: so should we put that distinction into BP2?

skarim: we should recognize it at the least

<jo> [skarim makes the point in reference to the "Web Run Time"

Bryan: i wanted to say that we have to think about the implication of ajax applications running in the browser so that transforming proxies can get out of the way if necessary

JonF: i think that we should target the web run time (as opposed to a browser sandbox) because by the time the documents are ready, this is where the industry will probably be

DKA: perhaps we should use the OpenAjax definition? what is it?

JonF: actually we need to adjust it -- but "Ajax is the use of browser functionality to achieve desktop like experiences without using proprietary plugins"

DKA: that last part I think is important to include in our BP2 scope -- we are talking about native web, open formats

skarim: i think we should avoid using the term "browser" at all when defining Ajax, focus on "web" technologies

jo: i'm concerned that the conversation is drifting into "best practices for the web runtime" which isn't necessarily what we're here to do

DKA: i think our recommendations can apply to both the "web" and the "web runtime"

jo: ok so i think we can say we are setting out to talk about the browser, but what we say may apply to the runtime/widget frameworks

<jo> PROPOSED RESOLUTION: The focus is on producing Best Practices that apply to the browser sandbox, while recognising that they may have broader applicability, esp Mobile Widgets

DKA: Jon, you mentioned that these Ajax toolkit people are going to be working on mobile. I think that brings to mind a question about the audience of our BP2 document.
... Are we going to be writing documents that can be consumed by toolkit creators, or content developers? If content developers, we should tell them to use toolkits where appropriate.

JonF: I think you should target both. Ultimately it's the content developers that are making choices about how much of the screen is needed, events, etc
... but the toolkit developers need to provide an interaction model that doesn't require a mouse (for example).

DKA: are we too late to target the toolkit developers?

JonF: No, in fact this is a good time because they haven't really started. There are a couple of toolkits that are mobile specific, but the mainstream ones are not and they are likely to win.

DKA: Can we get some information from the toolkit vendors about what they are doing for mobile? It would probably be useful input into the process.

PROPOSED RESOLUTION: The focus is on producing Best Practices that apply to the browser snadbox, while recognising that they may have broader applicability, esp Mobile Widgets

<jo> PROPOSED RESOLUTION: The focus is on producing Best Practices that apply to the browser sandbox, while recognising that they may have broader applicability, esp Mobile Widgets

DKA: do we need a resolution that says we acknowledge the difference between the browser sandbox and the web run time?

<jo> PROPOSED RESOLUTION: The focus is on producing Best Practices that apply to the browser sandbox, while recognising that they may have broader applicability to the Web Runtime, esp Mobile Widgets

Bryan: can we define "web run time"?

skarim: i believe it to be a set of libraries that provide an Ajax experience on a phone (CSS, javascript, offline storage) -- for example Google Gears, which
... wouldn't normally be thought of in the sandbox, could be in the web run time

<jo> PROPOSED RESOLUTION: The focus is on producing Best Practices that apply to the browser sandbox, while recognising that they may have broader applicability to the Web Runtime (CSS, HTML, Javascript, DOM, Persistent Storage), esp Mobile Widgets

DKA: so the run time isn't limited to the same sandbox as the browser -- it might have access to the filesystem? probably also doesn't have browser chrome (cites Joost as an example)

skarim: yes so XUL runner is a good example of a "web run time"

Bryan: ok that lines up well with my understanding -- we can probably generate best practices around how we'd like to deploy that in a mobile environment, but it's outside the browser sandbox

<jo> RESOLUTION: The focus of the BP2 document is on producing Best Practices that apply to the browser sandbox, while recognising that they may have broader applicability to the Web Runtime (CSS, HTML, Javascript, DOM, Persistent Storage, additional libraries, no browser chrome, cache, etc.), esp Mobile Widgets

<srowen> +1

DKA: can we take another resolution about focusing on content providers and also toolkit providers?

<jo> PROPOSED RESOLUTION: Audience of BP2 document will include CPs as well as Ajax and other toolkit developers

<jo> RESOLUTION: Audience of BP2 document will include CPs as well as Ajax and other toolkit developers

DKA: one last question for you Jon, what specifically would you like to see BP2 cover? -- can you look at our brainstorm list?

JonF: yes

<jo> [noted that Jon will provide feedback on the brainstorm from yesterday]

Kai: wondering why we are suddenly focusing only on Ajax? seems like we've changed direction, what about just building good mobile content?

DKA: i think we've addressed that in BP1. In my view, BP2 isn't only about Ajax, but is about building more complex applications, which necessarily involves Ajax.

Kai: but is that all there is to it?

Bryan: i think Ajax being on the table is reactive; we need a proactive strategy as part of BP2

DKA: but we are developing best practices for the use of existing technology. Ajax is in wide use on the web and is beginning to be used on the mobile web.

<jo> [dka claims not to be a fashion victim]

<Zakim> edm, you wanted to ask Jon for pointers to any existing OpenAjax resources/docs that might be relevant?

edm: ... can you point us at the material you mentioned?

DKA: I think he was referring to the workshop report, which is available.

jo: i think we have to say something about Ajax, but the general theme of BP2 is to stay abreast or ahead of the game -- so we should say what we can about Ajax
... but also about other technologies

[dka shocked that jo agrees with him]

Kai: ... i think we need to do some homework to get ahead of the game -- we need to lay the groundwork to make Ajax work well.

DKA: can you take an action to bring some items we need to consider to the table?

jo: need to close the topic...

skarim: i agree that we need to think we need to focus on best practices not about building ajax apps -- example: pop up menus
... an example of a best practice here: take the screen size into account so that your popup is visible. so this relates to Ajax, but is a basic best practice

<Kai> ACTION: Kai to write a summary of preliminary work to be done for this working group to focus on Best Practices for Web applications [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action01]

<trackbot-ng> Created ACTION-593 - Write a summary of preliminary work to be done for this working group to focus on Best Practices for Web applications [on Kai-Dietrich Scheppe - due 2007-11-13].


<DKA> ScribeNick: Bryan

<DKA> Scribe: Bryan

Phil: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Labels/20071018 was presented
... Plan is to goto last call on POWDER documents by end of next week.
... one open issue on precise structure of MobileOK claims, to be resolved this week

Dan: what is the acceptance by the RDF community for POWDER, will there be last call comments?

Phi: not a huge number of comments so far; detailed placement etc. No major objections so far.

Phil: May expect some last call comments but this has been in work for a long time, with charter expiration end of march, expect completion by then

Jo: any other questions?
... assumes user manuals will be last bit of work before March.

Phil: a primer is expected to be written. In Q1 2008 an event in London is expected to allow discusson. Other outreaches planned.

Jo: We can't make take the DR doc to the next step until POWDER is complete.

Phil: They do need to be sync'd. Last call on MobileOK Labels in a couple of weeks after POWDER should be OK.
... Final note, extensions are possible to labels. MWBP should define a vocabulary but other W3C groups can add their own metadata based upon that.

<srowen> I think our vocabulary is quite simple. At least we need vocab for "I am mobileOK"; at best we need "I have passed the following tests: AUTO_REFRESH..."

Jo: last call is due Q407. Briefly touching on next steps...
... MobileOK Basic will be in CR for a long time due to dependencies.
... More outreach would be helpful.
... If we are proactive, describing and writing explanatory documents it would motivate usage.

<Zakim> srowen, you wanted to give the answer to all these things

Sean: The next step is indeed CR, and it will be there for a while. The focus should be on checker. Announcement next week is expected.

Dan: If we are evaluating use of checker, and MobileOK is given, we could encourage use of the trust mark on sites.

Sean: We could post to our internal blogs etc to promote.

Jo: Would be good if someone could champion the overall publicity,

Dan: Dan can do it.

Mike: Where are we on the visual representation?

Jo: We have it.

Mike: How can we encourage its use if we don't have an approved use policy?

Jo: That's the job of the champion.

Kai: I did write something up on that.

<Zakim> MikeSmith, you wanted to comment on use of the thing that would otherwise be known as a trustmark

Jo: Kai has drafted text, it needs to be published as part of the scheme.

Dan: We need a MobileOK trustmark, and it needs to made available as part of the scheme. We need to enable distinction between just checking and being able to embed the trustmark.

Sean: A lot of new work, but not finishing existing work. We should focus on the deliverables on the radar, e.g. scheme. What do we need to do. We can promote this ourselves. Schema labels: what are they?

Jo: It would be best to see these drawn out into a useful form based upon Kai's input.

Phil: Unless something goes wrong, late Jan or early Feb at latest is expected.

Sean: What is the complication?

Phil: Proposes a teleconf to settle the work needed.

Sean: What are the moving parts?

Dan: Trustmark visual, rules, T&C's, liabilities, W3C issues: all kinds

Jo: You can't use the label until permission is granted.

<PhilA> ACTION: Dan to coordinate mobileOK Basic advancement, probably starting with a teleconf [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action02]

<trackbot-ng> Created ACTION-594 - Coordinate mobileOK Basic advancement, probably starting with a teleconf [on Daniel Appelquist - due 2007-11-13].

<Zakim> MikeSmith, you wanted to remind everybody about re-joining the group

Mike: reminder of two weeks left to rejoin the group.
... get your AC rep to rejoin you.

Jo: Need to herd people in the next two weeks.

<DKA> ACTION: Jo to encourage group participants to re-register themselves or have their AC reps re-register them for group membership in two weeks. [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action03]

<trackbot-ng> Created ACTION-595 - Encourage group participants to re-register themselves or have their AC reps re-register them for group membership in two weeks. [on Jo Rabin - due 2007-11-13].

Kai: MobileOK Basic are intended to be machine testable. MobileOK Pro addresses the human-testable tests. But very little progress so far.

<DKA> ACTION: Dan to encourage group participants to re-register themselves or have their AC reps re-register them for group membership in two weeks. [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action04]

<trackbot-ng> Created ACTION-596 - Encourage group participants to re-register themselves or have their AC reps re-register them for group membership in two weeks. [on Daniel Appelquist - due 2007-11-13].

Kai: On point is we need a means to ensure different people will come to the same assessment of success.
... Looking at MobileOK Pro document. Need be able to parameterize the tests.
... presenting http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Pro-1.0-Tests/latest
... Using drop down menus etc will benefit repeatability.
... Question to the group: does this fit the expectation to bracket the subjective tests?

Sean: Yes, the only plausible way to structure is not an algorithm, but as signposts to evaluate.

Kai: OK, challenges include rewriting all the tests. With the current resources this is not feasible.

Phi: It could be done with ability to focus on it.

Kai: But the concept is bracketing something subjective, which is not as easy.

Jo: Asking the question: does the group think it's still worthwhile to create mobile OK pro?

Kai: Yesterday we agreed to look into two documents going forward. A MobileOK Basic revamp may remove need for this document.

Jo: As a followup, should the group continue to produce MobileOK Pro?

Sean: History is that we planned MobileOK but it was too easy, so we needed Pro. The success of MOK Basic is TBD. For real success we need to see if a market develops around the verification.
... It's unclear there is a benefit for a human-based test. This is typical for work to start but not be finished.

Bryan: We may have input from the users of MobileOK Basic and Pro based upon how they use it.

<srowen> +1 to mothballing this until mobileOK Basic has had more time to "sink in", if anything

<Paul> Can someone kindly send me a link to a resouce where I can find what out what is 'currently' being discussed? Tks

Jo: Believes that people will use the checker, but it remains to be seen whether use of the trustmark or followup with MobileOK Pro will happen.

<edm> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Pro-1.0-Tests/20070716

Kai: Is sceptical about the need to continue with this document. We shoud consider this when we plan for BP2.

Phil: Worries about impacts, one is diminishing value of MobileOK Basic if we go no further.

<DKA> Paul, we are currently discussing MobileOK Pro - http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Pro-1.0-Tests/20070716.html - whether or not it makes sense to continue this work which does not seem to have much group support at this point, or to "mothball" it until MobileOK Basic has sunk in and enjoyed some use in the field.

Phil: Also casts question on the overall credibility of the process.

<Paul> +q

<srowen> I agree. I wish people who clamored for mobileOK Pro had not done so without intending to follow through.

Jo: Don't want the work abandoned, but it should not take years.

Phil: Is there a followup e.g. for BP2 that we could say we are following up with?

Jo: There is a lot of work getting started on BP2, MobileOK Labels, etc.

<DKA> paul - can you write in your comments?

<Paul> I only agreed to mobileOK basic on the premise that a proper Trustmark that incorporated all testable BPs would be created. It's easy for some organisations to only contribute to the areas that they are interested in. They should agree to and help to work towards delivering the brief (scope) as it was from the start

<Paul> Stopping here would only prove what I stated would happen in Boston last year when I was reassured by the same people, that we 'would' continue with mobileOK pro

<Paul> mobileOK basic is that; *basic*/ 'get out of jail free card' for the sake of early adoption/marketing. It's good but certainly not value for money

<srowen> Fair enough Paul, but, then why has nobody including you put work into mobileOK Pro? it's equally unfair to say that others should do work just because one organization does, and won't back that up with action

<srowen> er, where nobody = nobody except Kai

Jo: Finds it difficult to put a hold or moratorium on this. It's OK to reconsider, also need to be fair about the committments people are making or not.

Dan: Wonders if we put it to the group to have intense focus on this could we break ground on this, and the group could publish as a first working draft.

Kai: We have been there twice, a lot of words but not enough actions.

<Paul> Segala has put in a huge effort from day 1. For our size, we've probably contributed a higher % of manpower than any other organisation. We've gone through huge change recently with the upcoming launch of new applications that will help gain mass adoption for POWDER which in turn, will help mobileOK. I will put someone on this again if it means kick starting it properly

<Paul> ... it will mean taking someone off client paying project work but if it means adding value to industry rather than stopping here then I think it's worth it long term.

Phil: Given two-three days in the next few months, its possible, but we need a date.

Jo: That answers a concern; there may be motivation. The other question is does anyone have plans to deploy MobileOK Pro?

<Paul> ok I will give David Rooks for 4 complete man days this month. Who can work with him - I will personally put in some time too to help ensure David contributes on my behalf

<srowen> personally, no, wouldn't do that. clearly it has not been a priority, which begs us to ask whether there is a need right now for this doc. would anyone read it? pay for certification? direct resources to changing as a result? we do not have any evidence of this. I think it's entirely reasonable to leave this on hold indefinitely, therefore, until this changes

<Paul> +q

Jo: Need a clear mandate from the group, to be sure that the effort on MobileOK will be useful.

<Paul> Google has never seen it as important - so with respect...

<DKA> Paul -- did you want to speak up on the topic of putting "Pro" into commercial deployment?

<Paul> Yes

Phil: Agrees that marketeers like to promote their content and will be interested.

<Paul> Segala has finished the build of an application which automatically generates Certificates and POWDER (Content Labels). We're going to give it away for free to other Trustmark Providers to help build the ecosystem for enabling trust using Content Labels. Pro is what Segala will be encouraging as a goal after basic has been achieved

Jo: How can we bring this to conclusion, including getting a clear mandate, and set expectations on support?
... Kai will take an action to formulate what is needed.

<Kai> ACTION: kai to formulate a poll on what exactly people are planning on doing with mobileOK Pro, beyond issuing a mandate (potentially) [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action05]

<trackbot-ng> Created ACTION-597 - Formulate a poll on what exactly people are planning on doing with mobileOK Pro, beyond issuing a mandate (potentially) [on Kai-Dietrich Scheppe - due 2007-11-13].

Dan: We need to put dates down now to lock them in.

<Paul> We are delivering mobileOK compliance through or partner programme - agencies and freelancers who design, build and test web sites. We currently have 50 across 8 countries with no marketing. We aim to build it to 7,000 in 3 years with VC backing - of whom, many will encourage mobileOK

Jo: Kai can add options to a poll to capture interest.

Dan: We need to include dates.

<Kai> ACTION: Kai to add to the poll people's intention to participate in a MobileOK Pro Cram Session including dates for doing this [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action06]

<trackbot-ng> Created ACTION-598 - Add to the poll people's intention to participate in a MobileOK Pro Cram Session including dates for doing this [on Kai-Dietrich Scheppe - due 2007-11-13].

<Paul> Segala's interest represents potentially thousands of agencies. I Chair BIMA which represents the industry we are focused on - the feedback is, 'we really need this to help us build sites that work on mobiles'

<srowen> -> thinks Paul should focus on writing moblieOK Pro before hiring 7,000 people as mobileOK Pro consultants

Phil: Bruno, how does Mobile OK Pro help you?

<Paul> The partner programme is for awarding sites that are accessibility compliant to WCAG and Section 508. MobileOK is an extension to this

<Paul> but thanks for your concern sean :)

Bruno: Any step in the right direction is useful.

Phil: Is MobileOK Pro useful then?

Bruno: If it helps to improve the value of MobileOK.

Kai: MobileOK Pro will prevent the attitude that MobileOK Basic is all that is needed.

Jo: It's not necessary to bring both to market simultaneously, the growth will happen.

<Paul> +q

Sean: Worries that everyone will shoot for stickers. If this is just enabling someone to pay for a sticker there is a question on the usefulness.
... Would like to move this to a vote on mothballing the work. Curious to know the level of support.

<DKA> Paul, we are about to go for a coffee break right now so you get the last word on this topic.

<Paul> I agree with Kai - it's a bit like delivering WCAG Single-A and leaving it at that. We'd end up with a few more accessible sites, but not accessible enough for most people. I also agree with Jo that we don't need to deliver both simultaneously - they don't need to be consequtive either. Regarding Sean's comment; it's not necessary to buy a sticker.

<DKA> thx Paul.

<DKA> <break>

<Paul> Some kids like stickers, some with cry until they have one and some won't care. Enjoy your tea break, sorry I couldn't be there :)

Jo: We will take this forward once we have the answer to the poll.

<Kai> Here is the link to the usage guidelines I had posted to the mailing list

<Kai> http://lists.w3.org/Archives/Member/member-bpwg/2007Aug/0000.html

<Kai> ScribeNick: Kai

Jo and Dan: Welcoming the reps of WAI Outreach group

[Introductions commencing]

Jo: Background to why we are meeting here....

<DKA> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-20071031

Jo: had a discussion yesterday based on Alan's work where we thought of elevating his work from TF to the groups work in general
... if people are putting effort into meeting WCAG guidelines they can do the same for mobileOK
... we are entering CR with mobileOK Basic next week and announced the alpha version of our checker
... we would like to soon have a FPWD of Alan's work.

Shawn: have talked about the overlap for along time. Have spoken to Alan this morning and got some good feedback about what to do and we have some bigger issue that will affect timing, but are very supportive of it in general.

Jo: Objectives for this session then: an engagement plan to decide if the doc with its ref to WCAG 1.0 is acceptable with the view that 2.0 is just about with us.

Shawn: The LC WD is expected soon

Jo: How do we track the developement of WCAG 2.0?

Judy: WCAG 2.0 will be going to second LC next month.
... hope to go to CR a few months after that
... so WCAG 2.0 will be completed some time 2008
... we are doing harmonization work with other standards bodies
... while we like the approach of Alans work we are concerned about separate efforts going on
... we would like to harmonize there as well

Shawn: ideally FPWD would come out with WCAG 2.0 issues covered
... they are working on amapping of wcag 1.0 and 2.0
... the timeing issue has to do with resources as much as with the availability of the documents

Jo: the fact that there is section missing does not prevent going to FPWD?

Alan: it is not complete and will not be if we publish, but we can show the concept of including 2.0

Dan: you are calling for is a wcag 2.0 checkpoint?

Judy: I think that wcag 2.0 is going to be an advantage for developers
... they will have more leeway

Dan: that is part of the point of this document. We want develpers to get the most benefit from it.

alan: the document has two section one of bp of WCAG where it would corresspond to 2.0 and 1.0
... and the other section that corresponds to the BP

Jo: the point of hte FPWD is to lay down a marker.

alan: it would be much more work to do WCAG BP mapping
... changes would be complicated to fix
... better to put up example WCAG checkpoints

Shawn: We were leaning towards that that would be ok
... wanted to make sure it wasn't becoming WCAG 2.0

Jo: that seems to be the objective. It is not a complete document.

Dan: if I go through the doc and see a subheading of how something helps user withe disabilities that would be the spot to put a linkage to WCAG 2.0
... as a developer I would want the information to interleave in one document

Shawn: There are two sections to the document which is good and you can use what works best
... another point is to highlight the overlap of BP and accessbility then issueing the PD would be an important step
... we have been getting into presentation slides and have a business case for accesssibiltiy that mentions briefly the mobile world
... could we add a strong paragraph to the business case or some promo piece?

Jo: sounds like agood idea.
... we haven't plans for business case or doing outreach.
... we just touched upon it but would gladly be part of your documentation
... so perhaps we can move on to specifics.

Shawn: One tactical issue is the BP guide to the mobileOK tests....

Alan: if we say to accessibility people by doing this you comply with BP. Is that enough?

Dan: we have discussed this. The tests are very specific and I don't think we should map those back to WCAG...they are algorythmic

Jo: the keypoint is the suppose a fictious UA.
... it needs to be less specific for WCAG.

Sean: The tests map directly to the BP and it can be seen by the names. By passing the tests you pass part of the BP.
... while all of them are derived from WCAG you can spot similarities

Shawn: There might be some questions....when doing the mapping there might be some differneces or confusions

alan: haven't reviewed the basic tests thoroughly.
... as in page size there seem some discrepancies

Dan: they might have to do extra work to comply with the tests
... so that's ok and understood.

Sean: I think the intent is for the tests to map to the BP directly.
... it should be true that what is in the test should be in the BP.
... perhaps that clears up teh mapping

Wayne: we have had difficulty with automated testing
... how did you solve that problem?

Sean: We split the tests in machine testable and not machine testable

Alan: there is a difference in testing. The mobile BP deal with devices.

Dan: any dependance on human testing has been put into mobileOK Pro

jo: moving on to work plan
... what do you think is required from your side?

Shawn: We gave Alan feedback this morning and there are the empty section and we were able to assist with those.
... this morning we realized we wanted to do this and have to see how we get it done.
... it sounds like one of the question is the min requried for a FPWD
... we can soon say yes or no

Dan: Do we need joint TF
... I would prefer not to do so.

Shawn: I think it would fit into our group. Need to see if it fits, but hope it will.
... we need the time for it.

Judy: if it doesn't work we can spin off a TF
... so we might do that in parallel and you can send a delegate

Alan: perhaps we should have a shared mailing list.

Shawn: We will take an action to look at mailing lists.

<scribe> ACTION: Shawn to look at mailing lists for sharing information with between BP and WAI [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action07]

<trackbot-ng> Sorry, couldn't find user - Shawn

<scribe> ACTION: Alan to look at mailing list for sharing information between BP and WAI [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action08]

<trackbot-ng> Sorry, amibiguous username (more than one match) - Alan

<trackbot-ng> Try using a different identifier, such as family name or username (eg. achuter, abaldwin)

Shawn: I can look at the EO schedule and get back to Alan

<PhilA> action achuter to look at mailing list for sharing information between BP and EO

<PhilA> ACTION: achuter to look at mailing list for sharing information between BP and EO [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action09]

<trackbot-ng> Created ACTION-599 - Look at mailing list for sharing information between BP and EO [on Alan Chuter - due 2007-11-13].

Jo: Is there more you would like to cover...or anybody else?

Bruno: last time I saw WCAG it received +1000 comments
... how will we handle them? Should we discuss the process here and now?
... if this group can speak on some comments and send them to WCAG?

Judy: the last WD did not reveive that many comments, some 430
... the replies that came back on resolutions where pretty good.
... i think we pretty well probed the reactions.

Dan: we are not putting this document on the rec track.
... we are happy to receive public comment but we will have to respond to the comments

Judy: i don't want to create a specter

Jo: we need to be clear if this is a BP or WAI or both document

Judy: there are WAI resources but this will be a TR document.
... there are editors notes and my sense there will be room for a WG note.

Jo: Are we planning on a joint WG group note?

Judy: Why not?

Shawn: sounds good.

<PhilA> For example, there's a joint XHTML/SWD Note out now...

<srowen> scribenick: srowen

DKA: actions first

let's close all actions related to techniques for example

jo: ACTION-346 is subsumed into Kai's later action

PhilA: action was to raise an issue

jo: but we can't find it

srowen: must have been closed!

jo: it's now included in ACTION-594


PhilA; there's a whole task force!

jo: closing it


yes it was done


closing -- has to do with techniques


jo: done, but we did not follow up on this

DKA: create an issue

srowen: created ISSUE-226


Kai: also subsumed by later actoin


close it

ACTION-495 -- done

ACTION-503 -- done, decided not to move the call time

ACTION-519 -- done

ACTION-522 -- done

ACTION-523 -- task force and Arun no longer exist (er, in this WG)

so closing this actoin

ACTION-525 -- done

ACTION-530 -- need more time, we need this for BP 2

ACTION-531 -- close it

ACTION-536 -- close it, done

ACTION-540 -- up to CT to close this so move on

ACTION-541 -- pending review

ACTION-542 -- closed, copyrights are OK in the code

ACTION-543 -- done as far as this action is concerned

ACTION-544 -- yes done

ACTION-545 -- leave it open, srowen will do it

ACTION-546 -- done, close enough

ACTION-547 -- done

ACTION-549 -- done -- we do not foresee another meeting in the near future

ACTION-550 -- done

ACTION-559 -- done

ACTION-573 -- done, well, subsumed by ACTION-596

ACTION-576 -- closed, TF is not happening

ACTION-577 -- closed, we think

ACTION-578 -- done

ACTION-579 -- done

ACTION-580 -- still in progress

ACTION-582 -- should have been on srowen, but done

ACTION-583 -- done

<arun> Rumors about demise have been greatly exaggerated.

<arun> :-)

ACTION-584 -- ?

Bryan: yeah, basically done here. we did record that when we take it up again, we will want revisit possible changes to BPs

DKA: closing it then

jo: that's all we can do now

DKA: move on to issues. Let's timebox please -- 20 minutes left

jo: ISSUE-116

defer this until we have decided what to do on Pro


DKA: techniques! let's close it

jo: ISSUE-134, this is mobileOK Pro

ISSUE-139 -- closed, techniques

ISSUE-183 -- obsolete

ISSUE-184 -- closed, settled

ISSUE-185 -- leave it

ISSUE-187 -- leave it?

PhilA: not quite mobileOK Pro issue, but a one web issue

srowen: what is the issue here?
... no, don't htink there is any action

PhilA: bookmark example.com/page then redirect elsewhere

Bryan: yeah, not specific to mobile really

PROPOSED RESOLUTION: close ISSUE-187 as it is not specific to mobile and poses no particular problem to mobileOK or recommended BPs

jo: kind of want to think about this...

let us punt to CTT

ISSUE-188 -- ?

srowen: I wrote this text but don't believe a clarification is so important

jo: we need to think about this

srowen: let's talk now

Kai: this comes up in mobileOK Pro

jo: ISSUE-189, leave it

ISSUE-201, done

ISSUE-202 -- no tools task force, so close it

ISSUE-203 -- mobileOK Pro, leave it

ISSUE-204 -- close it

ISSUE-203 again -- actually, close it

ISSUE-210 -- skip it

ISSUE-211 -- close it, no longer needs discussion. schema is written, if possibly not consistent with output

ISSUE-214 -- skip it

ISSUE-225 -- ?

srowen: Imagine we don't have much to say here

no reason I think to argue to add or subtract from CSS MP 2.0

probably fine

jo: yes we probably won't have comments, let's close it

DKA: let's discuss next F2F

mikesmith: week before is OMA meeting in Beijing

a meeting after that week as ewll

for UWA

may be a chance to combine your travel plans

Jonathan: it's the same week actually

DKA: like a mini mobile plenary in Korea

want us to get more out of this than a F2F

like interaction with Mobile Web 2.0 forum

suggestions for other format issues?

jo: it is important to maximize value of the trip

let's not be too squeamish about the cost of travel -- colleagues from Korea frequently make the trip to participate in meetings in N. America and Europe

so let's focus on creating a series of events around this to maximize value of visiting

mikesmith: put together a program committee Jonathan?

DKA: yes, an organized and focused set of meetings is good. Action, Mike?

jo: Dan we trust you to represent us
... we trust Dan in all things

<jo> cough

mikesmith: Nothing further to say

jo: meeting is concluded
... [trails off into vague self-congratulatory statements]

Summary of Action Items

[NEW] ACTION: achuter to look at mailing list for sharing information between BP and EO [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action09]
[NEW] ACTION: Alan to look at mailing list for sharing information between BP and WAI [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action08]
[NEW] ACTION: Dan to coordinate mobileOK Basic advancement, probably starting with a teleconf [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action02]
[NEW] ACTION: Dan to encourage group participants to re-register themselves or have their AC reps re-register them for group membership in two weeks. [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action04]
[NEW] ACTION: Jo to encourage group participants to re-register themselves or have their AC reps re-register them for group membership in two weeks. [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action03]
[NEW] ACTION: Kai to add to the poll people's intention to participate in a MobileOK Pro Cram Session including dates for doing this [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action06]
[NEW] ACTION: kai to formulate a poll on what exactly people are planning on doing with mobileOK Pro, beyond issuing a mandate (potentially) [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action05]
[NEW] ACTION: Kai to write a summary of preliminary work to be done for this working group to focus on Best Practices for Web applications [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action01]
[NEW] ACTION: Shawn to look at mailing lists for sharing information with between BP and WAI [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action07]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/11/12 05:30:01 $