- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Mon, 12 Nov 2007 06:38:24 +0100
- To: public-bpwg <public-bpwg@w3.org>
Hi,
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:
http://www.w3.org/2007/11/06-bpwg-minutes
linked from
http://www.w3.org/2005/MWI/BPWG/Group/
and copied as text below. I'll also send separately a summary of the decisions
made during the meeting.
Dom
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
Attendees
Present
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
Regrets
Chair
Dan, Jo
Scribe
Phil, edm, MikeSmith, Aaron, Bryan
Contents
* [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
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>
[12]http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/Overview.htm
l
[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
<edm2z>
[14]http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-draf
ts/ProblemStatement/071008
[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
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>
[15]http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0057.
html
[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
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>
[17]http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0041.
html
[17] http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0041.html
<jo>
[18]http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0057.
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
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> [19]Possible Techniques for signalling capability/awareness or
preference
[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
[20]http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0035.
html
... refers to the list in
[21]http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0023.
html
... [continues to review the list above - in the spirit of HTTP
headerspotting??]
[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
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
Response
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]
[lunchtime]
<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...
... 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
[25]http://www.w3.org/2007/11/06-bpwg-minutes.html#action01]
[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].
mobileOK
<DKA> ScribeNick: Bryan
<DKA> Scribe: Bryan
Phil:
[26]http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Labels/200
71018 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
[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
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
[27]http://www.w3.org/2007/11/06-bpwg-minutes.html#action02]
[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]
[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
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
[29]http://www.w3.org/2007/11/06-bpwg-minutes.html#action04]
[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
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
[30]http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Pro-1.0-Te
sts/latest
... 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
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>
[31]http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Pro-1.0-Te
sts/20070716
[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 -
[32]http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Pro-1.0-Te
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,
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
[33]http://www.w3.org/2007/11/06-bpwg-minutes.html#action05]
[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]
[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
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>
[35]http://lists.w3.org/Archives/Member/member-bpwg/2007Aug/0000.htm
l
[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....
<DKA>
[36]http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/d
rafts/ED-mwbp-wcag-20071031
[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
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
[37]http://www.w3.org/2007/11/06-bpwg-minutes.html#action07]
[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]
[38] 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
[39]http://www.w3.org/2007/11/06-bpwg-minutes.html#action09]
[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
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
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
ACTION-476
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
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
ISSUE-122
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
[40]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
[41]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
[42]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
[43]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
[44]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
[45]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
[46]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
[47]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
[48]http://www.w3.org/2007/11/06-bpwg-minutes.html#action07]
[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