See also: minutes Day 1 - IRC log
<jo> Date: 6 Nov 2007
<PhilA> DKA: Begins meeting, suggests tour de table...
<PhilA> Dan and Jo sort out the logistics, scribes, agendas and so on
<PhilA> DKA: How many people here in CT TF?
<PhilA> four hands
<PhilA> scribeNick: PhilA
<scribe> scribe: Phil
There are 4 CT TF members present
<edm2z> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/Overview.html
Rhys: CT TF has 2 deliverables as
decided in London f2f
... 1 - to define problem statement (limited scope)
... guidelines document to help people avoid the pitfalls
<DKA> http://www.w3.org/TR/2007/WD-ct-landscape-20071025/
Rhys: Problem doc is now in TR space and will become a WG Note
<edm2z> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/ProblemStatement/071008
Rhys: Where there are multiple
players in delivery channel between server and client
... Is trying to work out how they can signal to each other as
they don't cuase errors in what each other does
... eg - material on origin server is already adapted for the
end device
... Found recent situations where intervening transforming
proxy has carried out inappropriate transformations
... purpose of TF is to work out what can flow between
participants to avoid that happening
... Focussed on using existing W3C tech to do it
... Therefore we're producing a guidelines doc, not a normative
Rec
Bryan: Do no harm, not do it better?
Rhys: Yes
... Who's read the doc?
Many hands go up
Rhys: Notes Bryan's
comments
... we have a skeleton guidelines doc and we're working on
filling in the blanks
... Jo has recently done some work on suitable signalling
... We're not just talking about proxies and servers - clients
have a role to play in user preferences
... User should have choice in whether they see transformed or
raw content
... Invites Jo to take us through his recent post
<edm2z> http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0057.html
<jo> Action Relating to Possible Techniques
DKA: A question in the meantime -
a lot of this was kicked off by the controversy about content
adaptation proxies not sending the UA string through
... Are we going to give content providers the guidance they
need or will it be so elaborate that it won't help?
Rhys: It wouldn't be productive
if we couldn't find a relatively simple solution
... The feeling I get is that there is a fighting chance of
coming up with some helpful guidance
DKA: My litmus test - I'd like to
be able to talk to developers without being booed down as
happens now...
... More seriously, you need not worry - here is what we, the
industry, are doing to fix this problem
Rhys: The idea that we'll provide something that can please most of the people most of the time is our aim
DKA: The message is - 'adapt your
content' - that's the way forward for the mobile web?
... The best outcome from this doc is that it fits into that
univese
Rhys: We're articulating how transforming proxies fit into that eco system
Bryan: The message that
developers get - we need to educate them to the nature of the
options that they have
... Either very specific to mobile, or adpating to mobile, or
not caring and leaving it up to adaptation
... We need to educate them what different headers can do and
why they should use them - and then move on
Jo: There are various options. One very narrow using HTTP and the other related to the scope of the guidelines doc
Slight hiatus while Jo and Dan do a jig for us all
Jo: This is a very dense debate. Bryan in particular, made some very useful comments...
<Rhys> http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0041.html
<jo> http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0057.html
Jo: The question is - how far do
you go?
... Are we trying to write a doc that tells people how not to
do any harm, or are we going to guide people through the whole
chain?
... The consensus seems to be that we're not going all the way
to the detail extreme
... Complicated by some browsers that act as proxies :-)
... A sequence of proxies may be treated as a unit of proxy
capability
... The issue at hand is - are we going to deliver the desktop
presentation or the specifically mobile-crafted version and
where is that latter version created, if it is created
... Bearing in mind that the WebKit [which both the Nokia S60
and Apple Safari and iPhone browsers use as their backend] can
do a lot, how does the server know what the browsser is able to
do?
... Given that the browser is not able to provide the mobile
experiecne on its own and the server may be able to, how do we
get the mix right?
... There are 64 permutations I reckon
... Each of the 3 components can do one of 2 types of
transformation
... At the markup level they can clean up markup, compress
images etc. This seems different from re-formatting of content,
including or excluding some etc.
Rhys: There are lots of options
for how the differnt entities can react to each other
... The complete set of options is large
... e.g. is the server can or can't negotiate to come up with a
mobile version etc
... we should minimise the number of things we address in the
initial doc as we have very limited time for the TF
... Then again, if we miss out key use cases, then we'll be
skipping too lightly
Bryan: I can add a summary of the
conversation...
... Let me try and get some yes/no in/out statements
... Whether to offer choice to user? Yes
... How to offer chocie? No
... Behaving as requested? Yes
... Protecting from harm? Yes
... Avoid non-web app harm? Yes
Rhys: Is this in an e-mail?
Bryan: yes, but this is a
summary
... Objectives - usability and interop - yes
... Optimisation, personalisation, content control - grey
areas
... If it becomes a policy point then I'd say No
Jo: Good summary of the kinds of
things we've been pondering - broadly I agree
... Might be worth working through some use cases
... Case 1 - the classic case that the server only has a
deskptop only presentation and the server only has
desktop
... In this case it is possible that the server's presentation
may be universal and so will lay out properly in either
... In general that's not the case
... A personal feeling - proxies should do what they do
reluctantly, more in sorrow than anger.
<Zakim> achuter, you wanted to mention mobileOK complication
<Zakim> Kai, you wanted to ask about layout independent presentation
Kai: I noticed a potential use case missing - a layout-neutral presentation. Maybe an XML instance provides the data and the layout is separate
Jo: Yes, but I think what we're
trying to do, erm, I don't think that's a use case that we want
to consider at the moment
... Stylesheet application etc. But that's not what we're
talking about within our scope with limited timeline
... Case 2 - server has both mobile and desktop presentation
available
... Assuming that the content provider's wishes are honoured,
the user will get the mobile presentation - with the caveat
that there should be a way for the user to specify the desktop
presentationb
... If both content provider and user both express preferences
and they're different, who wins?
... CP may be able to say I don't care what you want, I'm
sending you this
ack: sea
seanP: Usually the user
preference will prevail
... There's some discussion about whether the mobile page is
better than the transformed desktop page, but sometimes the
desktop page may have more content that the user actually
wants
... If the mobile version is a summary, there are cases where
the suer wants the full content, irrespective of the fact it
looks awful...
ack: sean
Rhys: Where we do have a user
preference, it's pretty straightforward - we should honour the
user's preference
... Where the user doesn't have the ability doesn't have the
choice then the author gets the next shout
... (i.e. if you don't know what the user wants)
<Zakim> Kai, you wanted to speak of prior experiences with providing desktop content for mobile users
Kai: We've tried for a long time
to take desktop content and make it work for mobile - and it
doesn't work
... User choice would be good - and we should store that choice
for next time
... On an editorial level, there's far more info on a desktop
page than a typical mobile page. We've tried to create
condensed versions automagically and it doesn't work - you have
to create 2 separate instances
<Rhys> acl dka
DKA: We're straying into
policy
... Shouldn't we be transparent for all parties so everyone
knows what's going on?
... If you have enough info so the browser, proxy, server and
user know what's available, then you can use business rules to
work out what to do
Rhys: Interesting. That speaks to
the guidelines scope
... It should probably say that if you don't know the user
preferences you should use the adapted conte,t not transcoded
contnet. Then you might expose that policy as a
user-configurable option - but that sounds like a level up from
where we're at
Jo: I agree
... I don't thinkwe should specify policy, but we should
illuminate that there are policy choices to be made
... ANd we should provide a vocabulary to enact those
policies
... e.g. we might say 'in general, CP, it is bad practice to be
hard-nosed about re-formatting, especially in terms of removal
of bad mark-up etc.
... However, I don't think we should remove the option from the
CP to say 'I know what I'm doing'.
... Even if they don't, that's probably not the point. It's
their content and ultimately, that's the war
... SO we can summariese the policy choices, here's the vocab
to express those policies, and we think you should use option x
and leave it at that
... If the operator of the proxy thinks that untransformed
content will cuase a problem then the user should be warned
Bryan: As Rhys said, we're trying
to solve the problems, not opening up new ones. The key thing
is how to express the desire?
... There has to be some understanding of intent
... We need to figure out how to signal intent in a dynamic
way
Rhys: Yes - we need to work out techniques for that and that should work in the absence of intent as well
SeanP: The proposed 'do not transform' header does that, but I think there should be another like 'do not transform unless you know you can do a better job' or whatever
Sean: There's a limited number of options but it's more than binary
<Zakim> Kai, you wanted to mention the conflict of user choice vs. provider choice. Both needs to be possible, but may not be easy to do simultaneously. Give providers tools to do what
Kai: Users may well not
understand the choices...
... There's a need to give CPs the tools to do it right.
Whether they use them or not is an open question
<edm2z> scribe: edm
<edm2z> scribenick: edm2z
jo: whose preferences should take priority is not always a straightforward question ...
<jo> [note to self - bookmark the "roaming issue"]
rhys: operator and user position may be influenced by cost issues
DKA: e.g., user may be happy to use desktop version with fast data service, mobile otherwise ...
SeanP: mobile browsers may be unable to deal with some types of content (e.g., Flash), but proxies could adapt these...
rhys: we do not want to encourage using separate URIs for accessing desktop vs. mobile friendly content
<jo> [kai sometimes neither the cp or the user knows what hey want, are we going to provide some guidelines]
rhys: everyboby should now have a good idea of the anticipated scope of CT guidelines
<jo> Possible Techniques for signalling capability/awareness or preference
PhilA: content personalization is out-of-scope, but could it be considered to be a useful extension of CT ?
Bryan: we should narrow the primary focus of CT to interoperability and usability
rhys: initial scope is very narrow - to solve a particluar problem - but we do not want to limit potential future functionality of adaptation proxies
jo: let's start discussing
specific techniques - see
http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0035.html
... refers to the list in
http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Oct/0023.html
... [continues to review the list above - in the spirit of HTTP
headerspotting??]
rhys: these techniques may not be universally usable - can a transforming proxy be informed by the UA header what to do ?
PhilA: huge amount of info may
have to be crammed into a couple of headers - should we focus
on what info would be most useful?
... other W3C groups are already working on the issue of how to
communicate certain info ...
Bryan: we should come up with a simplest possible solution to the problem - not necessarily overload the existing semantics
srowen: simple is best - we should recommend not changing original UA
<kemp> [actually sean is advocating _changing_ the user agent to the proxy's useragent]
<srowen> (srowen paraphrases himself: proxy should not do anything but say "I am a proxy" in its User-Agent. Therefore don't recommend anything but what proxies are doing today for the request. No need to overload, stretch, or invent mechanisms. 20, 21, and 23 are existing simple way to communicate "I may adapt content". Proxy merely redirects to origin server and gets out of the way. So 20, 21, 23 seem to solve it all nicely to me.)
rhys: we try to overloading existing HTTP semantics - but educating about its proper use makes sense
jo: we are not chartered to create new technology - should leverage what exists, bt also point out any constraints we may be running into
<MikeSmith> Scribenick: MikeSmith
Rhys: We just completed discussion on what role and additional User-Agent header might play.
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"
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]
jo: this is a little rococo
...
... certainly fits in with the existing rules of HTTP
Option 7: Embed original HTTP headers as part of the multipart MIME-encoded elaboration of the request as a message/http part
Rhys: Are we aware of any examples of where passing other headers through causes any problems?
jo: The are two separate cases ...
Rhys: question is which headers are actually expected and can we find a way to pass them through.
Point 8. Extend the interpretation of host or nickname field in the Via header
jo: HTTP says you can drop comments from the Via header ...
<Rhys> The point was that there are other headers that an origin server might use. An alternative mechanism to the multipart mime approach is simply not to replace those other headers. The decision on whether or not to repace other headers is the same one as whether or not to replace the user agent header
jo: so information can be lost
and we can't rely on it being preserved
... Question is, are these comment parts every actually dropped
[in practice]
Alternative is to use an X-Via header
scribe: which is defined as a copy of the Via header but with comments always preserved
so all the above was a discussion related of Request [stuff]
now on discussion of Response stuff
jo: As a content provider, you may be aware of potential markup cases that could cause problems with certain handsets but you don't fix those because you choose to leave it up to CT proxies or something to deal with instead.
Rhys: CT proxies are providing
value by solving those kinds of problems.
... In this TF we are talking about CT proxies that transform
the current Web
Bryan: You can extend Cache-Control to more than just No-Transform
Point 22: Taste the content
Point 23: Look for link elements
kemp: The "look for LINK
elements" practice is out there and widely used ...
... so we do need to acknowledge it
SeanP: back to 300 response
...
... question: Is it used already with some default body that we
would end up stomping on?
Bryan: Are we chartered to create new uses, new headers?
Rhys: My view is no, we are
not.
... we might conclude that we can't do this just by producing a
guidelines document ...
... but there is at least a fighting chance that some
combination of them will in fact do what we need ...
<Rhys> ack 300
DKA: If we do decide to do
something with 300, we need to be very sure to [do thorough
research on it]
... get some findings
<PhilA> new methods, headers, or extension mechanisms, but may introduce new
<PhilA> protocol elements if necessary as part of revising existing
<PhilA> functionality which has proven to be problematic"
jo: whatever we do come up with will require a thorough period of testing ...
<Zakim> PhilA, you wanted to quote from HTTP WG charter: "The WG is not tasked with producing
Rhys: Anybody have anything to add to the list?
DKA: We are focusing on the
server and network side ...
... but so far, not address the case of advanced browsers
...
... being able to communicate [their advanced-ness]
kemp: I think some of these do address the case of allowing a browser to communicate its capabilities
jo: I think there are some things
outside of what Aaron already mentioned ...
... potential use or misuse of Pragma, for example
Rhys: A mechanism for
transmitting the notion that the user has made a choice
...
... about what he or she wants to see
DKA: What I was talking about was
more on the guidelines side of things
... Also, I'm worried about this "tasting" thing ...
[DKA mentions problem of someone putting an item into shopping cart twice]
Bryan: We do need to address how [some of this has potential] to break Web applications.
<scribe> Scribe: MikeSmith
[discussion about communication with IETF]
DKA: Important that we are not trying to invent an adaptation solution in this group
Rhys: I think we need to be
careful to use phrases like "not aware" ...
... we have other cases where [because of old server software
or whatever] we need for the chain to be robust ...
... which is where things like tasting come into play
SeanP: About
tasting/differentiating ...
... if we are talking about use of existing stuff like the LINK
element [then OK]
Rhys: We have added a good number
of topics which are now going to be the subject of further work
...
... we have achieved a lot today, as far as what we can manage
to get done at this f2f
DKA: What we are seeing in the
field now ...
... is that people are already using a new header
... and we can perhaps give guidance on what the actual
nomenclature of the header should be
srowen: My personal view is that
we do not need a new header
... would rather tell people to use X-Device-User-Agent
...
... or whatever is in use ...
DKA: Big question is: Which one do we suggest they use?
SeanP: I obviously don't have a
problem with use an X-User-Agent header
... but I agree there is a problem with several different
headers [being used for the same purpose in the wild today]
<Zakim> rob, you wanted to support Rhys and Sean - ie let's see
RobFinean: I just want to support
what Rhys has been saying ...
... we need to look [at the big picture first]
<srowen> (srowen paraphrases himself again: let's not wait to codify a brand new official header. takes too long anyway. I don't want to glorify this mechanism anyway. Just pick a commonly used x- header for this purpose and go forward)
SeanP: The fact that these
solutions already exist ...
... one thing you might conclude is that the way it's already
being done [is in fact the best way]
PhilA: There is potential for
wanting to say quite complex things ...
... there is a lot of potential complexity there ...
... the HTTP headers can give you only basic information
...
... There is a lot more richness to this than can be put into
HTTP headers ...
jo: Is there any need to [put this information into HTTP headers etc.] if it is possible for the information to be obtained from using something like a Device Description repository ...
Rhys: Value in transmitting user preferences ...
jo: So we are going to try to simplify the use cases to the set of use cases that are the leading ones [in terms of actual current practice]
Rhys: I think you all have just agreed to not be surprised when you see our first working draft [laugh]
[we meet back at 13:15 to talk again about Charter II]
[lunchtime]
<jo> scribenick: kemp
<scribe> scribenick: kemp
<MikeSmith> Scribe: Aaron
DKA: [introducing our ajax visitor and referencing our proposed resolution yesterday to make two documents]
<MikeSmith> http://www.w3.org/2007/06/mobile-ajax/
<edm> http://www.w3.org/2007/06/mobile-ajax/
<MikeSmith> http://www.w3.org/2007/06/mobile-ajax/report.html
john: ... talking about the
origin of ajax and the OpenAjax alliance...
... alliance includes mobile oriented companies, but was
focusing on the desktop. launched the mobile taskforce with
rhys as chair
<jo> [speaker is Jon Ferraiolo of IBM/OPen Ajax Alliance]
JonF: a workshop was held...
wrapup findings included the belief that there will (at some
point) be a common Ajax platform between desktop/mobile
... many vendors are now using webkit or other high end
browsers for modern phones.
DKA: (at the event) i remarked that we are seeing convergence between desktop and mobile, so what we'll end up with is the web, on mobile, instead of the mobile web
JonF: from a developer point of
view, we're seeing the creation of javascript libraries that
web content developers use instead of writing HTML or
JavaScript directly.
... however these libraries are not yet there for mobile --
mobile is the next big thing on their list (especially with the
iphone/nokia webkit browsers)
... back to OpenAjax -- the overall goal is how can we help the
industry advance so that these technologies will deliver rich
applications on mobile devices.
... in general, the industry seems to be doing well on its own
-- we primarily want to focus on education
... so we want to issue whitepapers, talking about the current
state of the industry and the standard techniques, but not get
into details about how to make a good application
... another group (the best practices) would develop a set of
best practices based on the whitepapers from OpenAjax
... (discussion about desktop/mobile sharing of
libraries/runtimes)
skarim: some issues may still arise, because the execution environment on the mobile is more limited than a desktop (eg processor speed, memory, bandwidth)
Bryan: was there any presumption about the runtime environment and how it would compare to the desktop? i think the presumption is that it would be inside the browser sandbox
JonF: yes there was a focus on the browser sandbox, but we talked about widget frameworks so that ajax applications would be installable as mini applications
<Zakim> skarim, you wanted to comment about browser sandbox vs. web runtime
DKA: we talked about this a bit yesterday when talking about the scope of BP2 -- for the purposes of BP2, I think the practices can be applied in either case
skarim: there is a distinct difference between browser sandboxes and widget shells
DKA: so should we put that distinction into BP2?
skarim: we should recognize it at the least
<jo> [skarim makes the point in reference to the "Web Run Time"
Bryan: i wanted to say that we have to think about the implication of ajax applications running in the browser so that transforming proxies can get out of the way if necessary
JonF: i think that we should target the web run time (as opposed to a browser sandbox) because by the time the documents are ready, this is where the industry will probably be
DKA: perhaps we should use the OpenAjax definition? what is it?
JonF: actually we need to adjust it -- but "Ajax is the use of browser functionality to achieve desktop like experiences without using proprietary plugins"
DKA: that last part I think is important to include in our BP2 scope -- we are talking about native web, open formats
skarim: i think we should avoid using the term "browser" at all when defining Ajax, focus on "web" technologies
jo: i'm concerned that the conversation is drifting into "best practices for the web runtime" which isn't necessarily what we're here to do
DKA: i think our recommendations can apply to both the "web" and the "web runtime"
jo: ok so i think we can say we are setting out to talk about the browser, but what we say may apply to the runtime/widget frameworks
<jo> PROPOSED RESOLUTION: The focus is on producing Best Practices that apply to the browser sandbox, while recognising that they may have broader applicability, esp Mobile Widgets
DKA: Jon, you mentioned that
these Ajax toolkit people are going to be working on mobile. I
think that brings to mind a question about the audience of our
BP2 document.
... Are we going to be writing documents that can be consumed
by toolkit creators, or content developers? If content
developers, we should tell them to use toolkits where
appropriate.
JonF: I think you should target
both. Ultimately it's the content developers that are making
choices about how much of the screen is needed, events,
etc
... but the toolkit developers need to provide an interaction
model that doesn't require a mouse (for example).
DKA: are we too late to target the toolkit developers?
JonF: No, in fact this is a good time because they haven't really started. There are a couple of toolkits that are mobile specific, but the mainstream ones are not and they are likely to win.
DKA: Can we get some information from the toolkit vendors about what they are doing for mobile? It would probably be useful input into the process.
PROPOSED RESOLUTION: The focus is on producing Best Practices that apply to the browser snadbox, while recognising that they may have broader applicability, esp Mobile Widgets
<jo> PROPOSED RESOLUTION: The focus is on producing Best Practices that apply to the browser sandbox, while recognising that they may have broader applicability, esp Mobile Widgets
DKA: do we need a resolution that says we acknowledge the difference between the browser sandbox and the web run time?
<jo> PROPOSED RESOLUTION: The focus is on producing Best Practices that apply to the browser sandbox, while recognising that they may have broader applicability to the Web Runtime, esp Mobile Widgets
Bryan: can we define "web run time"?
skarim: i believe it to be a set
of libraries that provide an Ajax experience on a phone (CSS,
javascript, offline storage) -- for example Google Gears,
which
... wouldn't normally be thought of in the sandbox, could be in
the web run time
<jo> PROPOSED RESOLUTION: The focus is on producing Best Practices that apply to the browser sandbox, while recognising that they may have broader applicability to the Web Runtime (CSS, HTML, Javascript, DOM, Persistent Storage), esp Mobile Widgets
DKA: so the run time isn't limited to the same sandbox as the browser -- it might have access to the filesystem? probably also doesn't have browser chrome (cites Joost as an example)
skarim: yes so XUL runner is a good example of a "web run time"
Bryan: ok that lines up well with my understanding -- we can probably generate best practices around how we'd like to deploy that in a mobile environment, but it's outside the browser sandbox
<jo> RESOLUTION: The focus of the BP2 document is on producing Best Practices that apply to the browser sandbox, while recognising that they may have broader applicability to the Web Runtime (CSS, HTML, Javascript, DOM, Persistent Storage, additional libraries, no browser chrome, cache, etc.), esp Mobile Widgets
<srowen> +1
DKA: can we take another resolution about focusing on content providers and also toolkit providers?
<jo> PROPOSED RESOLUTION: Audience of BP2 document will include CPs as well as Ajax and other toolkit developers
<jo> RESOLUTION: Audience of BP2 document will include CPs as well as Ajax and other toolkit developers
DKA: one last question for you Jon, what specifically would you like to see BP2 cover? -- can you look at our brainstorm list?
JonF: yes
<jo> [noted that Jon will provide feedback on the brainstorm from yesterday]
Kai: wondering why we are suddenly focusing only on Ajax? seems like we've changed direction, what about just building good mobile content?
DKA: i think we've addressed that in BP1. In my view, BP2 isn't only about Ajax, but is about building more complex applications, which necessarily involves Ajax.
Kai: but is that all there is to it?
Bryan: i think Ajax being on the table is reactive; we need a proactive strategy as part of BP2
DKA: but we are developing best practices for the use of existing technology. Ajax is in wide use on the web and is beginning to be used on the mobile web.
<jo> [dka claims not to be a fashion victim]
<Zakim> edm, you wanted to ask Jon for pointers to any existing OpenAjax resources/docs that might be relevant?
edm: ... can you point us at the material you mentioned?
DKA: I think he was referring to the workshop report, which is available.
jo: i think we have to say
something about Ajax, but the general theme of BP2 is to stay
abreast or ahead of the game -- so we should say what we can
about Ajax
... but also about other technologies
[dka shocked that jo agrees with him]
Kai: ... i think we need to do some homework to get ahead of the game -- we need to lay the groundwork to make Ajax work well.
DKA: can you take an action to bring some items we need to consider to the table?
jo: need to close the topic...
skarim: i agree that we need to
think we need to focus on best practices not about building
ajax apps -- example: pop up menus
... an example of a best practice here: take the screen size
into account so that your popup is visible. so this relates to
Ajax, but is a basic best practice
<Kai> ACTION: Kai to write a summary of preliminary work to be done for this working group to focus on Best Practices for Web applications [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action01]
<trackbot-ng> Created ACTION-593 - Write a summary of preliminary work to be done for this working group to focus on Best Practices for Web applications [on Kai-Dietrich Scheppe - due 2007-11-13].
<DKA> ScribeNick: Bryan
<DKA> Scribe: Bryan
Phil:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Labels/20071018
was presented
... Plan is to goto last call on POWDER documents by end of
next week.
... one open issue on precise structure of MobileOK claims, to
be resolved this week
Dan: what is the acceptance by the RDF community for POWDER, will there be last call comments?
Phi: not a huge number of comments so far; detailed placement etc. No major objections so far.
Phil: May expect some last call comments but this has been in work for a long time, with charter expiration end of march, expect completion by then
Jo: any other questions?
... assumes user manuals will be last bit of work before
March.
Phil: a primer is expected to be written. In Q1 2008 an event in London is expected to allow discusson. Other outreaches planned.
Jo: We can't make take the DR doc to the next step until POWDER is complete.
Phil: They do need to be sync'd.
Last call on MobileOK Labels in a couple of weeks after POWDER
should be OK.
... Final note, extensions are possible to labels. MWBP should
define a vocabulary but other W3C groups can add their own
metadata based upon that.
<srowen> I think our vocabulary is quite simple. At least we need vocab for "I am mobileOK"; at best we need "I have passed the following tests: AUTO_REFRESH..."
Jo: last call is due Q407.
Briefly touching on next steps...
... MobileOK Basic will be in CR for a long time due to
dependencies.
... More outreach would be helpful.
... If we are proactive, describing and writing explanatory
documents it would motivate usage.
<Zakim> srowen, you wanted to give the answer to all these things
Sean: The next step is indeed CR, and it will be there for a while. The focus should be on checker. Announcement next week is expected.
Dan: If we are evaluating use of checker, and MobileOK is given, we could encourage use of the trust mark on sites.
Sean: We could post to our internal blogs etc to promote.
Jo: Would be good if someone could champion the overall publicity,
Dan: Dan can do it.
Mike: Where are we on the visual representation?
Jo: We have it.
Mike: How can we encourage its use if we don't have an approved use policy?
Jo: That's the job of the champion.
Kai: I did write something up on that.
<Zakim> MikeSmith, you wanted to comment on use of the thing that would otherwise be known as a trustmark
Jo: Kai has drafted text, it needs to be published as part of the scheme.
Dan: We need a MobileOK trustmark, and it needs to made available as part of the scheme. We need to enable distinction between just checking and being able to embed the trustmark.
Sean: A lot of new work, but not finishing existing work. We should focus on the deliverables on the radar, e.g. scheme. What do we need to do. We can promote this ourselves. Schema labels: what are they?
Jo: It would be best to see these drawn out into a useful form based upon Kai's input.
Phil: Unless something goes wrong, late Jan or early Feb at latest is expected.
Sean: What is the complication?
Phil: Proposes a teleconf to settle the work needed.
Sean: What are the moving parts?
Dan: Trustmark visual, rules, T&C's, liabilities, W3C issues: all kinds
Jo: You can't use the label until permission is granted.
<PhilA> ACTION: Dan to coordinate mobileOK Basic advancement, probably starting with a teleconf [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action02]
<trackbot-ng> Created ACTION-594 - Coordinate mobileOK Basic advancement, probably starting with a teleconf [on Daniel Appelquist - due 2007-11-13].
<Zakim> MikeSmith, you wanted to remind everybody about re-joining the group
Mike: reminder of two weeks left
to rejoin the group.
... get your AC rep to rejoin you.
Jo: Need to herd people in the next two weeks.
<DKA> ACTION: Jo to encourage group participants to re-register themselves or have their AC reps re-register them for group membership in two weeks. [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action03]
<trackbot-ng> Created ACTION-595 - Encourage group participants to re-register themselves or have their AC reps re-register them for group membership in two weeks. [on Jo Rabin - due 2007-11-13].
Kai: MobileOK Basic are intended to be machine testable. MobileOK Pro addresses the human-testable tests. But very little progress so far.
<DKA> ACTION: Dan to encourage group participants to re-register themselves or have their AC reps re-register them for group membership in two weeks. [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action04]
<trackbot-ng> Created ACTION-596 - Encourage group participants to re-register themselves or have their AC reps re-register them for group membership in two weeks. [on Daniel Appelquist - due 2007-11-13].
Kai: On point is we need a means
to ensure different people will come to the same assessment of
success.
... Looking at MobileOK Pro document. Need be able to
parameterize the tests.
... presenting
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Pro-1.0-Tests/latest
... Using drop down menus etc will benefit repeatability.
... Question to the group: does this fit the expectation to
bracket the subjective tests?
Sean: Yes, the only plausible way to structure is not an algorithm, but as signposts to evaluate.
Kai: OK, challenges include rewriting all the tests. With the current resources this is not feasible.
Phi: It could be done with ability to focus on it.
Kai: But the concept is bracketing something subjective, which is not as easy.
Jo: Asking the question: does the group think it's still worthwhile to create mobile OK pro?
Kai: Yesterday we agreed to look into two documents going forward. A MobileOK Basic revamp may remove need for this document.
Jo: As a followup, should the group continue to produce MobileOK Pro?
Sean: History is that we planned
MobileOK but it was too easy, so we needed Pro. The success of
MOK Basic is TBD. For real success we need to see if a market
develops around the verification.
... It's unclear there is a benefit for a human-based test.
This is typical for work to start but not be finished.
Bryan: We may have input from the users of MobileOK Basic and Pro based upon how they use it.
<srowen> +1 to mothballing this until mobileOK Basic has had more time to "sink in", if anything
<Paul> Can someone kindly send me a link to a resouce where I can find what out what is 'currently' being discussed? Tks
Jo: Believes that people will use the checker, but it remains to be seen whether use of the trustmark or followup with MobileOK Pro will happen.
<edm> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Pro-1.0-Tests/20070716
Kai: Is sceptical about the need to continue with this document. We shoud consider this when we plan for BP2.
Phil: Worries about impacts, one is diminishing value of MobileOK Basic if we go no further.
<DKA> Paul, we are currently discussing MobileOK Pro - http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Pro-1.0-Tests/20070716.html - whether or not it makes sense to continue this work which does not seem to have much group support at this point, or to "mothball" it until MobileOK Basic has sunk in and enjoyed some use in the field.
Phil: Also casts question on the overall credibility of the process.
<Paul> +q
<srowen> I agree. I wish people who clamored for mobileOK Pro had not done so without intending to follow through.
Jo: Don't want the work abandoned, but it should not take years.
Phil: Is there a followup e.g. for BP2 that we could say we are following up with?
Jo: There is a lot of work getting started on BP2, MobileOK Labels, etc.
<DKA> paul - can you write in your comments?
<Paul> I only agreed to mobileOK basic on the premise that a proper Trustmark that incorporated all testable BPs would be created. It's easy for some organisations to only contribute to the areas that they are interested in. They should agree to and help to work towards delivering the brief (scope) as it was from the start
<Paul> Stopping here would only prove what I stated would happen in Boston last year when I was reassured by the same people, that we 'would' continue with mobileOK pro
<Paul> mobileOK basic is that; *basic*/ 'get out of jail free card' for the sake of early adoption/marketing. It's good but certainly not value for money
<srowen> Fair enough Paul, but, then why has nobody including you put work into mobileOK Pro? it's equally unfair to say that others should do work just because one organization does, and won't back that up with action
<srowen> er, where nobody = nobody except Kai
Jo: Finds it difficult to put a hold or moratorium on this. It's OK to reconsider, also need to be fair about the committments people are making or not.
Dan: Wonders if we put it to the group to have intense focus on this could we break ground on this, and the group could publish as a first working draft.
Kai: We have been there twice, a lot of words but not enough actions.
<Paul> Segala has put in a huge effort from day 1. For our size, we've probably contributed a higher % of manpower than any other organisation. We've gone through huge change recently with the upcoming launch of new applications that will help gain mass adoption for POWDER which in turn, will help mobileOK. I will put someone on this again if it means kick starting it properly
<Paul> ... it will mean taking someone off client paying project work but if it means adding value to industry rather than stopping here then I think it's worth it long term.
Phil: Given two-three days in the next few months, its possible, but we need a date.
Jo: That answers a concern; there may be motivation. The other question is does anyone have plans to deploy MobileOK Pro?
<Paul> ok I will give David Rooks for 4 complete man days this month. Who can work with him - I will personally put in some time too to help ensure David contributes on my behalf
<srowen> personally, no, wouldn't do that. clearly it has not been a priority, which begs us to ask whether there is a need right now for this doc. would anyone read it? pay for certification? direct resources to changing as a result? we do not have any evidence of this. I think it's entirely reasonable to leave this on hold indefinitely, therefore, until this changes
<Paul> +q
Jo: Need a clear mandate from the group, to be sure that the effort on MobileOK will be useful.
<Paul> Google has never seen it as important - so with respect...
<DKA> Paul -- did you want to speak up on the topic of putting "Pro" into commercial deployment?
<Paul> Yes
Phil: Agrees that marketeers like to promote their content and will be interested.
<Paul> Segala has finished the build of an application which automatically generates Certificates and POWDER (Content Labels). We're going to give it away for free to other Trustmark Providers to help build the ecosystem for enabling trust using Content Labels. Pro is what Segala will be encouraging as a goal after basic has been achieved
Jo: How can we bring this to
conclusion, including getting a clear mandate, and set
expectations on support?
... Kai will take an action to formulate what is
needed.
<Kai> ACTION: kai to formulate a poll on what exactly people are planning on doing with mobileOK Pro, beyond issuing a mandate (potentially) [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action05]
<trackbot-ng> Created ACTION-597 - Formulate a poll on what exactly people are planning on doing with mobileOK Pro, beyond issuing a mandate (potentially) [on Kai-Dietrich Scheppe - due 2007-11-13].
Dan: We need to put dates down now to lock them in.
<Paul> We are delivering mobileOK compliance through or partner programme - agencies and freelancers who design, build and test web sites. We currently have 50 across 8 countries with no marketing. We aim to build it to 7,000 in 3 years with VC backing - of whom, many will encourage mobileOK
Jo: Kai can add options to a poll to capture interest.
Dan: We need to include dates.
<Kai> ACTION: Kai to add to the poll people's intention to participate in a MobileOK Pro Cram Session including dates for doing this [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action06]
<trackbot-ng> Created ACTION-598 - Add to the poll people's intention to participate in a MobileOK Pro Cram Session including dates for doing this [on Kai-Dietrich Scheppe - due 2007-11-13].
<Paul> Segala's interest represents potentially thousands of agencies. I Chair BIMA which represents the industry we are focused on - the feedback is, 'we really need this to help us build sites that work on mobiles'
<srowen> -> thinks Paul should focus on writing moblieOK Pro before hiring 7,000 people as mobileOK Pro consultants
Phil: Bruno, how does Mobile OK Pro help you?
<Paul> The partner programme is for awarding sites that are accessibility compliant to WCAG and Section 508. MobileOK is an extension to this
<Paul> but thanks for your concern sean :)
Bruno: Any step in the right direction is useful.
Phil: Is MobileOK Pro useful then?
Bruno: If it helps to improve the value of MobileOK.
Kai: MobileOK Pro will prevent the attitude that MobileOK Basic is all that is needed.
Jo: It's not necessary to bring both to market simultaneously, the growth will happen.
<Paul> +q
Sean: Worries that everyone will
shoot for stickers. If this is just enabling someone to pay for
a sticker there is a question on the usefulness.
... Would like to move this to a vote on mothballing the work.
Curious to know the level of support.
<DKA> Paul, we are about to go for a coffee break right now so you get the last word on this topic.
<Paul> I agree with Kai - it's a bit like delivering WCAG Single-A and leaving it at that. We'd end up with a few more accessible sites, but not accessible enough for most people. I also agree with Jo that we don't need to deliver both simultaneously - they don't need to be consequtive either. Regarding Sean's comment; it's not necessary to buy a sticker.
<DKA> thx Paul.
<DKA> <break>
<Paul> Some kids like stickers, some with cry until they have one and some won't care. Enjoy your tea break, sorry I couldn't be there :)
Jo: We will take this forward once we have the answer to the poll.
<Kai> Here is the link to the usage guidelines I had posted to the mailing list
<Kai> http://lists.w3.org/Archives/Member/member-bpwg/2007Aug/0000.html
<Kai> ScribeNick: Kai
Jo and Dan: Welcoming the reps of WAI Outreach group
[Introductions commencing]
Jo: Background to why we are meeting here....
<DKA> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-20071031
Jo: had a discussion yesterday
based on Alan's work where we thought of elevating his work
from TF to the groups work in general
... if people are putting effort into meeting WCAG guidelines
they can do the same for mobileOK
... we are entering CR with mobileOK Basic next week and
announced the alpha version of our checker
... we would like to soon have a FPWD of Alan's work.
Shawn: have talked about the overlap for along time. Have spoken to Alan this morning and got some good feedback about what to do and we have some bigger issue that will affect timing, but are very supportive of it in general.
Jo: Objectives for this session then: an engagement plan to decide if the doc with its ref to WCAG 1.0 is acceptable with the view that 2.0 is just about with us.
Shawn: The LC WD is expected soon
Jo: How do we track the developement of WCAG 2.0?
Judy: WCAG 2.0 will be going to
second LC next month.
... hope to go to CR a few months after that
... so WCAG 2.0 will be completed some time 2008
... we are doing harmonization work with other standards
bodies
... while we like the approach of Alans work we are concerned
about separate efforts going on
... we would like to harmonize there as well
Shawn: ideally FPWD would come
out with WCAG 2.0 issues covered
... they are working on amapping of wcag 1.0 and 2.0
... the timeing issue has to do with resources as much as with
the availability of the documents
Jo: the fact that there is section missing does not prevent going to FPWD?
Alan: it is not complete and will not be if we publish, but we can show the concept of including 2.0
Dan: you are calling for is a wcag 2.0 checkpoint?
Judy: I think that wcag 2.0 is
going to be an advantage for developers
... they will have more leeway
Dan: that is part of the point of this document. We want develpers to get the most benefit from it.
alan: the document has two
section one of bp of WCAG where it would corresspond to 2.0 and
1.0
... and the other section that corresponds to the BP
Jo: the point of hte FPWD is to lay down a marker.
alan: it would be much more work
to do WCAG BP mapping
... changes would be complicated to fix
... better to put up example WCAG checkpoints
Shawn: We were leaning towards
that that would be ok
... wanted to make sure it wasn't becoming WCAG 2.0
Jo: that seems to be the objective. It is not a complete document.
Dan: if I go through the doc and
see a subheading of how something helps user withe disabilities
that would be the spot to put a linkage to WCAG 2.0
... as a developer I would want the information to interleave
in one document
Shawn: There are two sections to
the document which is good and you can use what works
best
... another point is to highlight the overlap of BP and
accessbility then issueing the PD would be an important
step
... we have been getting into presentation slides and have a
business case for accesssibiltiy that mentions briefly the
mobile world
... could we add a strong paragraph to the business case or
some promo piece?
Jo: sounds like agood idea.
... we haven't plans for business case or doing outreach.
... we just touched upon it but would gladly be part of your
documentation
... so perhaps we can move on to specifics.
Shawn: One tactical issue is the BP guide to the mobileOK tests....
Alan: if we say to accessibility people by doing this you comply with BP. Is that enough?
Dan: we have discussed this. The tests are very specific and I don't think we should map those back to WCAG...they are algorythmic
Jo: the keypoint is the suppose a
fictious UA.
... it needs to be less specific for WCAG.
Sean: The tests map directly to
the BP and it can be seen by the names. By passing the tests
you pass part of the BP.
... while all of them are derived from WCAG you can spot
similarities
Shawn: There might be some questions....when doing the mapping there might be some differneces or confusions
alan: haven't reviewed the basic
tests thoroughly.
... as in page size there seem some discrepancies
Dan: they might have to do extra
work to comply with the tests
... so that's ok and understood.
Sean: I think the intent is for
the tests to map to the BP directly.
... it should be true that what is in the test should be in the
BP.
... perhaps that clears up teh mapping
Wayne: we have had difficulty
with automated testing
... how did you solve that problem?
Sean: We split the tests in machine testable and not machine testable
Alan: there is a difference in testing. The mobile BP deal with devices.
Dan: any dependance on human testing has been put into mobileOK Pro
jo: moving on to work plan
... what do you think is required from your side?
Shawn: We gave Alan feedback this
morning and there are the empty section and we were able to
assist with those.
... this morning we realized we wanted to do this and have to
see how we get it done.
... it sounds like one of the question is the min requried for
a FPWD
... we can soon say yes or no
Dan: Do we need joint TF
... I would prefer not to do so.
Shawn: I think it would fit into
our group. Need to see if it fits, but hope it will.
... we need the time for it.
Judy: if it doesn't work we can
spin off a TF
... so we might do that in parallel and you can send a
delegate
Alan: perhaps we should have a shared mailing list.
Shawn: We will take an action to look at mailing lists.
<scribe> ACTION: Shawn to look at mailing lists for sharing information with between BP and WAI [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action07]
<trackbot-ng> Sorry, couldn't find user - Shawn
<scribe> ACTION: Alan to look at mailing list for sharing information between BP and WAI [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action08]
<trackbot-ng> Sorry, amibiguous username (more than one match) - Alan
<trackbot-ng> Try using a different identifier, such as family name or username (eg. achuter, abaldwin)
Shawn: I can look at the EO schedule and get back to Alan
<PhilA> action achuter to look at mailing list for sharing information between BP and EO
<PhilA> ACTION: achuter to look at mailing list for sharing information between BP and EO [recorded in http://www.w3.org/2007/11/06-bpwg-minutes.html#action09]
<trackbot-ng> Created ACTION-599 - Look at mailing list for sharing information between BP and EO [on Alan Chuter - due 2007-11-13].
Jo: Is there more you would like to cover...or anybody else?
Bruno: last time I saw WCAG it
received +1000 comments
... how will we handle them? Should we discuss the process here
and now?
... if this group can speak on some comments and send them to
WCAG?
Judy: the last WD did not reveive
that many comments, some 430
... the replies that came back on resolutions where pretty
good.
... i think we pretty well probed the reactions.
Dan: we are not putting this
document on the rec track.
... we are happy to receive public comment but we will have to
respond to the comments
Judy: i don't want to create a specter
Jo: we need to be clear if this is a BP or WAI or both document
Judy: there are WAI resources but
this will be a TR document.
... there are editors notes and my sense there will be room for
a WG note.
Jo: Are we planning on a joint WG group note?
Judy: Why not?
Shawn: sounds good.
<PhilA> For example, there's a joint XHTML/SWD Note out now...
<srowen> scribenick: srowen
DKA: actions first
let's close all actions related to techniques for example
jo: ACTION-346 is subsumed into Kai's later action
PhilA: action was to raise an issue
jo: but we can't find it
srowen: must have been closed!
jo: it's now included in ACTION-594
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]