W3C home > Mailing lists > Public > public-bpwg@w3.org > November 2007

[minutes] F2F Meeting Day 2 - 6 November 2007 (TPAC)

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Mon, 12 Nov 2007 06:38:24 +0100
To: public-bpwg <public-bpwg@w3.org>
Message-Id: <1194845904.17470.43.camel@cumulustier>


The Mobile Web Best Practices Working Group had a two-days F2F meeting
last week in Cambridge, MA, as part of the TPAC 2007 week [1].

The minutes of the second day of meeting are available at:
linked from

and copied as text below. I'll also send separately a summary of the decisions
made during the meeting.


1. http://www.w3.org/2007/11/TPAC/

           Mobile Web Best Practices Working Group F2F Day 2

6 Nov 2007

   See also: [2]minutes Day 1 - [3]IRC log

      [2] http://www.w3.org/2007/11/05-bpwg-minutes
      [3] http://www.w3.org/2007/11/06-bpwg-irc


          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


     * [4]Topics
         1. [5]Add the real user agent as part of the massaged user
            agent string
         2. [6]Tasting of content with original header.
         3. [7]Use an Expect header
         4. [8]Response
         5. [9]Workshop on Mobile Ajax
         6. [10]mobileOK
     * [11]Summary of Action Items

   <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

   <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


     [12] 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> [13]http://www.w3.org/TR/2007/WD-ct-landscape-20071025/

     [13] http://www.w3.org/TR/2007/WD-ct-landscape-20071025/

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


     [14] 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
   ... 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
   ... Invites Jo to take us through his recent post


     [15] http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0057.html

   <jo> [16]Action Relating to Possible Techniques

     [16] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/575

   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

   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...


     [17] http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0041.html


     [18] 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
   ... 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
   ... 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

   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

   <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> [19]Possible Techniques for signalling capability/awareness or

     [19] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/575

   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
   ... refers to the list in
   ... [continues to review the list above - in the spirit of HTTP

     [20] http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0035.html
     [21] http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0023.html

   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

   <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

   <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
   ... Question is, are these comment parts every actually dropped [in

   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
   ... 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
   ... Also, I'm worried about this "tasting" thing ...

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

   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
   ... 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

   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> [22]http://www.w3.org/2007/06/mobile-ajax/

     [22] http://www.w3.org/2007/06/mobile-ajax/

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

     [23] http://www.w3.org/2007/06/mobile-ajax/

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

     [24] http://www.w3.org/2007/06/mobile-ajax/report.html

   john: ... talking about the origin of ajax and the OpenAjax
   ... 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
   ... 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

   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

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

   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

   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

     [25] 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

   71018 was presented
   ... Plan is to goto last call on POWDER documents by end of next
   ... one open issue on precise structure of MobileOK claims, to be
   resolved this week

     [26] http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Labels/20071018

   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

   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
   ... 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

   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

   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

   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

     [27] 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

     [28] 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

   <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

     [29] 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

   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
   ... Using drop down menus etc will benefit repeatability.
   ... Question to the group: does this fit the expectation to bracket
   the subjective tests?

     [30] http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Pro-1.0-Tests/latest

   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

   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


     [31] 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 -
   sts/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.

     [32] http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Pro-1.0-Tests/20070716.html

   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,

   <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

   <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

     [33] 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

     [34] 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
   ... 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


     [35] 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....


     [36] 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

   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
   ... 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

   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
   ... 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
   ... 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

   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

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

   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
   ... 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

     [37] 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

     [38] http://www.w3.org/2007/11/06-bpwg-minutes.html#action08

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

   <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

     [39] 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
   ... 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

   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

   DKA: ACTION-403

   PhilA; there's a whole task force!

   jo: closing it

   DKA: ACTION-416

   yes it was done

   DKA: ACTION-430

   closing -- has to do with techniques


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

   DKA: create an issue

   srowen: created ISSUE-226

   DKA: ACTION-483

   Kai: also subsumed by later actoin

   DKA: ACTION-491

   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

   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

   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,

   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
   [NEW] ACTION: Alan to look at mailing list for sharing information
   between BP and WAI [recorded in
   [NEW] ACTION: Dan to coordinate mobileOK Basic advancement, probably
   starting with a teleconf [recorded in
   [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
   [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
   [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
   [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
   [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
   [NEW] ACTION: Shawn to look at mailing lists for sharing information
   with between BP and WAI [recorded in

     [40] http://www.w3.org/2007/11/06-bpwg-minutes.html#action09
     [41] http://www.w3.org/2007/11/06-bpwg-minutes.html#action08
     [42] http://www.w3.org/2007/11/06-bpwg-minutes.html#action02
     [43] http://www.w3.org/2007/11/06-bpwg-minutes.html#action04
     [44] http://www.w3.org/2007/11/06-bpwg-minutes.html#action03
     [45] http://www.w3.org/2007/11/06-bpwg-minutes.html#action06
     [46] http://www.w3.org/2007/11/06-bpwg-minutes.html#action05
     [47] http://www.w3.org/2007/11/06-bpwg-minutes.html#action01
     [48] http://www.w3.org/2007/11/06-bpwg-minutes.html#action07

   [End of minutes]
Received on Monday, 12 November 2007 05:39:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:51 UTC