See also: IRC log
<jo> Poll for F2F
Jo: There has been a poll.
<dom> Results of Poll for next F2F
Jo: We have a nominal date and
some offers of hosting.
... Vodafone?
<jsmanrique> dom: maybe it is me
Dan: No confirmation as of today.
<jsmanrique> chaals: it is me ;)
Jo: We have offers from Chaals in
Norway.
... Reason I am keen on London - it's easy for people to get
to.
<jo> (and Darmstadt)
Jo: Firm offers from Norway and
Darmstadt.
... survey says: 9-11 December
<jo> PROPOSED RESOLUTION: F2F 9-11 in TBD (maybe London on the basis of Transport costs and ease)
<brucel> + Iceland will be cold
+1
<tomhume> +1
<jeffs> +1
<jsmanrique> +1
<yyesilad> +1
<SeanP> +1
<EdC> Ok.
Dan: I will get back to y'all suckers by tomorrow.
<jo> ACTION: Dan to get back to group on hosting F2F by tomorrow [recorded in http://www.w3.org/2009/09/29-bpwg-minutes.html#action01]
<trackbot> Created ACTION-1016 - Get back to group on hosting F2F by tomorrow [on Daniel Appelquist - due 2009-10-06].
<chaals> s/suckers, and chaals/
<dom> Adam's update
Adam: I've sent in a draft with minor mods from last week - hopefully it's good to go.
Jo: Any comments in on that yet?
Adam: Not yet.
Jo: Editorial meeting?
Adam: Let's discuss a date...
+1 to dom
<jeffs> I think Dom is right
<Zakim> dom, you wanted to wonder about publishing as LC before editorial meeting
<jeffs> 24 sept
<jeffs> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20090924
<jo> PROPOSED RESOLUTION: Request publication of 24 Sept draft of MWABP as Last Call
<jo> +1
<jeffs> +1
<adam> +1
+1
<Zakim> dom, you wanted to ask what groups we want reviews from and to ask about deadline for comments
<dom> Dom: I recommend WebApps, DAP, HTML, SVG, maybe CSS, WAI, I18N
Jo: A month seems right to me.
RESOLUTION: Request publication of 24 Sept draft of MWABP as Last Call
<jeffs> +1
<EdC> +1
RESOLUTION: Request publication of 24 Sept draft of MWABP as Last Call with a comment period of a month with comments requested from WebApps, DAP, HTML, SVG, maybe CSS, WAI, I18N
<brucel> "3.5.10 did we have a note r/e accessibility there?
<adam> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20090924
Jo: Editorial meeting...
<dom> "In most cases Canvas is faster and should be preferred if it meets requirements. However, since Canvas generates a flat bitmap it is not inherently accessible and so should not be used as the sole means of conveying information. "
<dom> ACTION: Francois to get MWABP published as Last Call and ensure Chairs announcement is properly sent [recorded in http://www.w3.org/2009/09/29-bpwg-minutes.html#action02]
<trackbot> Created ACTION-1017 - Get MWABP published as Last Call and ensure Chairs announcement is properly sent [on François Daoust - due 2009-10-06].
<jo> ACTION: Adam to call editorial meeting on Friday 9th Oct to discuss MWABP [recorded in http://www.w3.org/2009/09/29-bpwg-minutes.html#action03]
<trackbot> Created ACTION-1018 - Call editorial meeting on Friday 9th Oct to discuss MWABP [on Adam Connors - due 2009-10-06].
<brucel> Bruce, must duck out for a few minutes; knock on the door
Jo: some comments from chaals - some to and fro - and it's unresolved...
<dom> Charles' suggestion
Dom: To clarify, what decision needs to be made?
<jo> Chaals's proposal ref ACcessKey
<dom> +1 on adopting Charles's suggestion and publish
Jo: either we adopt chaal's suggestion, update and publish or ignore and publish.
<jo> PROPOSED RESOLUTION: Adopt Chaals's resolution, request update from editor and publish
+1 if Chaals brings us some ice from iceland.
<EdC> 0
<tomhume> 0
<jsmanrique> +1
<jeffs> "while there is no standard way ..."??
<jeffs> "While there is no standard way... , common techniques include..."???
<chaals> +1 to chaals comments
<jo> PROPOSED RESOLUTION: Thanks Chaals for his informed comment but we decline to adjust the text and request publication as is
<EdC> 0
<jeffs> I think we can put the 2 of them together, his point is well-taken
<jeffs> "While there is no standard way... , common techniques include...", for example???
<chaals> -1 to the foolish and reckless proposal to ignore the brilliant and insightful yet minimal change proposed by chaals
<jsmanrique> :)
RESOLUTION: Adopt Chaals's resolution, request update from editor and publish
<dom> CT latest draft (1v)
<dom> Charles' point on conformance
Jo: We have a document -
<dom> Charles's point on URI patterns
Jo: ...on which there are some
substantive comments...
... ...chaals points out the conformance statement needs to be
mandatory...
... fairly simple change.
... A further suggestion on URI patterns - we have ended up in
debate on the list that it would be better to express the URI
pattern in a known pattern language. I'm happy to make that
change.
<dom> Charles' message on "interacting with the user"
Jo: Third point was: "what does interacting with the user actually mean"?
<dom> Jo's unthreaded reply
Jo: What do we need to put in the
document, if anything, to clarify our intention and our
meaning?
... Chaals?
Chaals: <stunned silence>
Jo: Ed can you clarify?
EdC: You mentioned it would be going too far to specify in detail how the interaction between proxy and user should take place. I agree - we should keep silent.
Jo: It's probably worth adding a note.
Tom: Chaals mentions 2 possibilities - one is ??? - other is that proxy generates http responses. If it's the 2nd doesn't that mean that the proxy could be compliant but the user could not see any difference?
Jo: We've looked a long time ago at -300 status responses and such. It's pretty clear that will not work. We mean interacting with the user "in band." We should clarify that it is "in band" with the communication with the web site that user is trying to interact with.
Chaals: I.e. content that is served directly to the user. We may get objections to that. This is a fairly serious step. Given that all providers assume that they have no bugs, they are unlikely to want to interrupt their rendering with a confusing statement...
<EdC> This is not how it is done. In general there is something like a link with a comment "click here to unmodified content" or so.
Jo: Yes but user does need to be given the option.
<jeffs> user *must* have choice/control
Chaals: There are other
mechanisms. This is a substantive issue. When the user has
chosen a preference they should have an expectation that this
preference will be applied.
... If you change your preferences (in Opera Mini) through your
UI preferences settings, is that an "in band" preference
dialog?
Jo: Opera mini is out of scope for this document.
Dom: point 1- in interacting with
the user it's clear that we meant "in band" communication.
point 2- is this a reasonable requirement and will we get
people to follow that requirement. Chaals is saying he might
object.
... Can we hear from other vendors?
Chaals: Opera software does not provide the in-band notification that you're asking for and i can't imagine they would...
Jo: One objection people have often taken to proxies is that operators [of proxies] feel free to insert in-band content...
Chaals: If you're interested in compliance then requirements which have a direct user experience impact, you need to be clear that these are necessary...
<EdC> +q
Jo: It's not acceptable for there
to be pre-configured proxies, where signing a t&c gives
carte blanche to the proxy operator.
... It's not in scope for us to design the UI or operation of
the product.
<EdC> -q
<Zakim> tomhume, you wanted to find chaals' suggestion on http response codes more reasonable
Jo: What's in scope is that the product should provide a way for the user to tell the proxy [to get out of the way]
Chaals: if there is a proxy that is explicitly non-transparent, adding options on the bottom will not be helpful...
Jo: We're not trying to develop a interface document that referes to user-cognitive models [?]
<EdC> I think Chaals you should realize that in many cases, users do not explicitly subscribe to a non-transparent service -- it is imposed by the operator.
Sean: I agree with Dan - maybe we should leave things the way they are. What constitutes in-band or out of band - that seems to be hard to define...
Jo: I agree.
Chaals: 2 issues - does "in band" mean inserted into the rendered page? If so, there must be some minimum explanation of "inform the user and allow the user to choose."
Jo: My preference would be to remain silent. 2nd point - if we are not to remain silent then text needs to say "provide user with a choice at the point of receipt of the content."
<jeffs> agree that choice should be provided at point of content-receipt
<EdC> Dan, you mean some for of "interstitial" or "splash" option setting page?
Dan: "in band" notification could be an interstitial page, as in a wifi hotspot...
Chaals: it's not nice to have an interstitial. You should be able to set preferences out of band. Would that be a sufficient solution.
Jo: No I don't think it would be sufficient.
Sean: I think chaals's solution seems Ok as long as there's a link to it on the page that was sent down...
Jo: Inserting a link so you can change your preferences seems no less intrusive...
Chaals: What if you had a preferences setting?
EdC: The google wireless transcoder does exactly what Sean said. 2nd thing - regarding preferences: if you are setting preferences you are setting them for every possible link traversal. The intent of the guidelines is that when something exceptional happens, then at that point the user should be informed (rather than at every traversal).
Chaals: No because we set per-site preferences anyway.
<EdC> example in section 4.1.5.3 "but must, on receipt of an indication from a Web site that it offers alternative representations (see H.1.4.2 Indication of Intended Presentation Media Type of Representation), inform the user of that and allow them to select an alternative representation."
<EdC> This is not something that can be done out of band via preference settings.
<jo> PROPOSED RESOLUTION: LEave text as is in respect of interacting with the user
EdC: It'd doesn't mean that out-of-band preferences (e.gg. per site) should not be used but that it is not sufficient.
<SeanP> +1
<EdC> +1
<jo> +1
+1
<dom> [chaals says +1 on the phone, but noting that this leaves the possibility for people to claim conformance doing things we simply don't expect - on the other hand that is not the worst things possible]
<tomhume> +1
<jo> Sean's Comments
RESOLUTION: Leave text as is in respect of interacting the user [in CT]
Jo: In reference to validation to an appropriate published grammar. Are you asking for that clause to be changed?
<EdC> I believe we went through this, downgraded must to should validate (catering for if there is no grammar f.ex.), keeping only well-formed for XML.
Sean: Yes. Seems
unrealistic.
... I don't think any of them do that today.
<EdC> See my comment above.
<dom> [I think Sean's point is reasonable indeed]
Sean: HTML typically doesn't validate and sometimes to get it work the way you want it can't validate...
Jo: Any comments?
<EdC> I believe we went through this, downgraded must to should validate (catering for if there is no grammar f.ex.), keeping only well-formed for XML.
<dom> "The altered content should validate according to an appropriate published formal grammar and if XML must be well-formed;"
<EdC> This means no published or no formal grammar => no validation. Otherwise should, but if you have reasons to tweak to make it work...
Jo: I think this provides plenty of room in the conformance statement - scope for you to conform but not to validate in certain cases.
<EdC> Yes. Only XML has a formal definition and separation of validation and well-formed (the latter being lexically/syntactically correct).
Sean: OK that's fine. I just wanted to make sure that's what we're saying.
Jo: Let's leave it as that.
PROPOSED RESOLUTION: let's roll
<EdC> Who takes up the editorial comments of SeanP?
Jo: any other comments?
<jo> PROPOSED RESOLUTION: Modulo the two editorial adjustments inspired by Chaals, (not including user interaction) and Sean's rightfully critical editorial comments, the group requests publication of the draft 1v as Last Call
<EdC> Do not forget the ICS...
<EdC> Include it in the resolution...
<dom> ScribeNick: dom
<jo> PROPOSED RESOLUTION: Modulo the two editorial adjustments inspired by Chaals, (not including user interaction) and Sean's rightfully critical editorial comments, the group requests publication of the draft 1v (together wit the corresponding ICS) as Last Call
<EdC> +1
+1
<jo> +1
<SeanP> +1
<chaals> 0
[DKA +1 on the phone]
previous list of people asked for comments: TAG, HTML WG, XHTML2 WG, WebApps WG, HCG , OMA (at least)
<jo> PROPOSED RESOLUTION: Modulo the two editorial adjustments from Chaals, (not including user interaction) and Sean's editorial comments, the group requests publication of the draft 1v (together wit the corresponding ICS) as Last Call with 4 weeks and request comments from same list as last time as well as previous LC commenters
<EdC> +1
<adam> +1
<jo> +1
<SeanP> +1
<brucel> concur
RESOLUTION: Modulo the two editorial adjustments from Chaals, (not including user interaction) and Sean's editorial comments, the group requests publication of the draft 1v (together wit the corresponding ICS) as Last Call with 4 weeks and request comments from same list as last time as well as previous LC commenters
Jo: 1 month period, same list of groups as before, plus commenters on previous draft
<scribe> ACTION: Francois to get CT published as Last Call and ensure chairs announcement [recorded in http://www.w3.org/2009/09/29-bpwg-minutes.html#action04]
<trackbot> Created ACTION-1019 - Get CT published as Last Call and ensure chairs announcement [on François Daoust - due 2009-10-06].