10:27:13 RRSAgent has joined #bpwg 10:27:14 logging to http://www.w3.org/2009/03/25-bpwg-irc 10:27:26 Zakim has joined #bpwg 10:27:50 Meeting: BPWG F2F London March 2009, Day 1 10:28:05 chair: jo 10:28:06 francois has joined #bpwg 10:28:42 francois has changed the topic to: BPWG F2F meeting in London 10:28:47 RRSAgent, draft minutes 10:28:48 I have made the request to generate http://www.w3.org/2009/03/25-bpwg-minutes.html francois 10:29:11 RRSAgent, make logs public 10:30:03 Present: Adam, Rob, SeanP, Jonathan, AlanC, Jo, Dan, Kai, francois 10:30:46 Agenda: http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London3/logistics.html#agenda 10:32:01 Regrets: I have none 10:32:50 zakim, room for 5? 10:32:51 ok, Jo; conference Team_(bpwg)10:32Z scheduled with code 26631 (CONF1) for 60 minutes until 1132Z 10:33:24 Team_(bpwg)10:32Z has now started 10:33:31 +Bryan_Sullivan 10:33:41 zakim, code? 10:33:41 the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), francois 10:33:43 zakim, codse? 10:33:44 I don't understand your question, Jo. 10:34:23 + +0207881aaaa 10:34:42 zakim, aaaa is berners_lee_at_google 10:34:42 +berners_lee_at_google; got it 10:35:18 achuter has joined #bpwg 10:35:37 zakim, berners_lee_at_google holds Jo, Francois, Alan, Jonathan, Kai, Adam, Rob, Sean, DKA 10:35:37 +Jo, Francois, Alan, Jonathan, Kai, Adam, Rob, Sean, DKA; got it 10:37:55 achuter has joined #bpwg 10:38:45 Scribe: Rob 10:38:50 DKA has joined #bpwg 10:38:51 ScribeNick: rob 10:40:49 adam has joined #bpwg 10:41:25 Topic: MWABP 10:41:46 http://docs.google.com/Doc?id=dft77cn8_35cvjfktc2&hl=en 10:43:14 adam: This doc contains a few comments from Bryan, Eduardo and Jeff and others and all the ToDos highlighted 10:43:58 Jo: shall we start going through in order? 10:44:37 adam: ok, starting at the top, can Francois reference the emails? 10:45:35 -> http://lists.w3.org/Archives/Member/member-bpwg/2009Mar/0057.html Bryan's latest comments on MWABP 10:45:49 seem to have lost the audio 10:46:42 -> http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0104.html Eduardo's comments on MWABP 10:47:28 -berners_lee_at_google 10:47:39 -> http://lists.w3.org/Archives/Member/member-bpwg/2009Mar/0036.html Jeff's comments on MWABP 10:48:28 +berners_lee_at_google 10:48:47 -> http://lists.w3.org/Archives/Member/member-bpwg/2009Mar/0051.html Jeff's ACTION-910 on use of canvas 10:50:01 -> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/290 ISSUE-290 raised by Jonathan 10:50:16 -> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/291 ISSUE-291 raised by Jonathan 10:50:28 http://www.w3.org/2008/webapps/wiki/Main_Page#Widgets 10:50:31 ? 10:50:36 DKA: reference this link into Web Apps WG? 10:51:59 ... this is the widgets section of the WG's wiki. As good as it gets 10:52:20 Jo: Is there nothing that says "this is what a widget is"? 10:52:31 DKA: no, too political!! 10:53:45 adam: Onto Eduardo's point about assumed device capabilities and baseline compliance... 10:53:55 Jo has joined #bpwg 10:54:08 ACTION: Dan to write a relevant section at Webapps Wiki to act as reference for On MWABP 1.3.2 DKA 10:54:08 Created ACTION-918 - Write a relevant section at Webapps Wiki to act as reference for On MWABP 1.3.2 DKA [on Daniel Appelquist - due 2009-04-01]. 10:54:15 ... Any suggestions for this? 10:54:31 DKA: isn't this an Advanced Delivery Context? 10:55:45 Jo: I'd prefer to leave as it is: being compliant with "JavaScript" or "HTMLx" is problematic 10:55:48 PROPOSED RESOLUTION: We will remain ambiguous in the document as regards compliance to specific language profiles... 10:56:10 +1 10:56:17 PROPOSED RESOLUTION: Replace 1.3.4 "Compliance" with "Capability" 10:56:42 +1 10:56:43 +1 10:57:09 +1 10:57:11 +1 10:57:43 RESOLUTION: Replace 1.3.4 "Compliance" with "Capability" 10:59:00 PROPOSED RESOLUTION: We don't think it worthwhile to propose specific versions of HTMLO, CSS, Javascript 10:59:18 s/HTML0/HTML/ 10:59:29 s/HTMLO/HTML/ 10:59:34 DKA: do we want specific resolution on not referencing specific language versions? 10:59:45 +1 to me 11:01:00 Bryan: given a lot of the doc is about "use the capabilities the device has" then don't we assume HTML5? 11:01:32 Jo: no, we're going to talk about capabilities like client-side-storage instead 11:01:51 DKA: this is coming up in the next point 11:02:35 dom has left #bpwg 11:02:37 +1 11:02:56 +1 11:02:58 +1 11:03:02 RESOLUTION: We don't think it worthwhile to propose specific versions of HTML, CSS, Javascript 11:03:05 +1 11:04:35 adam: Use client-size-storage. HTLM5, BONDI for example. 11:05:02 Bondi: http://www.omtp.org/bondi 11:06:27 DKA: This is OK as an informal reference for BONDI, because they're pre-release specs 11:06:58 SeanP: any implementations yet? 11:07:16 francois: no, but Symbian is close 11:07:39 Jo: this is a forward-looking BP 11:08:41 DKA: HTML5 client-side-storage is real on a number of handsets 11:09:08 s/client-size/client-side/ 11:10:09 s/Symbian is close/I heard David Wood from Symbian yesterday mention their intention to implement Bondi in 2009/ 11:10:09 adam: should we use the Offline Web Applications reference? 11:10:31 PROPOSED RESOLUTION: Generalise HTML 5 to "Client Size Storage" and add informative reference to BONDI 11:11:03 +1 11:11:07 +1 11:11:10 +1 11:11:13 +1 11:11:17 +1 11:11:21 +1 11:11:22 +1 11:12:15 +1 from Kai 11:12:25 RESOLUTION: Generalise HTML 5 to "Client Side Storage" and add informative reference to BONDI 11:14:24 http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0104.html 11:14:29 http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0129.html . Is it right ? 11:14:34 adam: question from Bryan and Eduardo is about is replicating client-side-storage on the server really a best practice or just another technique? 11:17:42 Bryan: it's not always necessary but server-based synchronisation of data between multiple devices is useful. Just don't want to discourage use of client-side-storage. 11:17:56 s/http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0129.html . Is it right ?// 11:18:12 adam: yes, rewording is wise to highlight this 11:18:32 s|s/http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0129.html . Is it right ?//|| 11:18:48 s|http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0129.html . Is it right ?|| 11:19:11 rrsagent, draft minutes 11:19:11 I have made the request to generate http://www.w3.org/2009/03/25-bpwg-minutes.html Jo 11:33:25 achuter has joined #bpwg 11:34:46 s/David Wood from Symbian/David Wood from Symbian [Post discussion note from francois: I most probably confused David from Symbian with Morgan Gillis from the Limo Foundation] 11:35:29 q? 11:36:55 adam: continuing onto minify: since this is the name of a specific tool we should avoid the word minify and explain what it does 11:37:51 Jo: or find another word (like compression or optimisation)? 11:40:19 DKA: but a search on "minify" yields lots of other references (inc Wikipedia definition) 11:41:18 JonathanJ has joined #bpwg 11:42:33 adam: can someone take an action to research a recommendation? 11:44:30 Jo: I think it's ok to say "minify" as a verb for this 11:46:34 ... and a note to explain we do not refer specifically to the minify utility 11:46:46 PROPOSED RESOLUTION: Leave in the word "minify" as we mean it in a generic sense (like hoover vs. Hoover in EN-GB) and write a Note: explaining the types of things we mean here 11:46:56 +1 11:46:58 +1 11:47:05 +1 11:47:08 +1 11:47:14 RESOLUTION: Leave in the word "minify" as we mean it in a generic sense (like hoover vs. Hoover in EN-GB) and write a Note: explaining the types of things we mean here 11:49:06 adam: Eduardo raised point that inline style-sheets isn't necessarily a good practice. Lack of cache can degrade performance 11:49:25 DKA: isn't this encapsulated in the word "consider"? 11:50:46 adam: if it's often not a good idea then perhaps we should not recommend even considering it to avoid confusion? 11:51:07 ... there is already a BP about minimising the number of requests 11:52:10 Jo: this is in MWBP1 11:52:45 adam: so let's remove 3.4.6 from MWABP 11:53:40 zakim, ping me in 7 minutes 11:53:40 ok, Jo 11:54:29 Jo: 3.4.6 does say a little bit more than MWBP 11:56:26 adam: but it is potentially going to mislead 11:56:51 PROPOSED RESOLUTION: Remove 3.4.6 ref inline style sheets and script 11:56:53 +1 11:56:56 +1 11:56:58 +1 11:57:03 +1 11:57:07 kscheppe has joined #bpwg 11:57:09 +1 11:57:17 RESOLUTION: Remove 3.4.6 ref inline style sheets and script 11:59:24 adam: onto 3.4.11/12: they say much the same thing. But we're suggesting doing something without concrete evidence that's it a big improvement. 12:00:40 Jo, you asked to be pinged at this time 12:00:43 ... Bryan suggested returning to the original wording but on a modern browser it's simply not a power concern 12:01:11 Jo: but it is a concern for discovery of content by search spiders etc 12:01:41 ... and "minimise time to first view" 12:03:31 PROPOSED RESOLUTION: Remove 3.4.11 and 3.4.12 as they are hard to quantify and are not actionable 12:04:31 Bryan: The original advice was submitted by Jose at Telefonica and was to start with a static HTML structure and manipulate that 12:05:22 adam: yes, it got less clear as the advice I disagreed with got removed. We're down to the point where this point does not add much value. 12:05:52 +1 12:06:07 +1 12:06:17 +1 12:06:21 ACTION: adam to ping Jose ref the battery and DOM manipulation question 12:06:21 Created ACTION-919 - Ping Jose ref the battery and DOM manipulation question [on Adam Connors - due 2009-04-01]. 12:06:27 RESOLUTION: Remove 3.4.11 and 3.4.12 as they are hard to quantify and are not actionable 12:07:16 PROPOSED RESOLUTION: instead of 3.4.11 and 3.4.12 have a section on Minimize time to first view 12:07:23 +1 12:07:24 +1 12:07:33 RESOLUTION: instead of 3.4.11 and 3.4.12 have a section on Minimize time to first view 12:08:30 adam: 3.5.2 Use Scripting could be combined into "avoid page reloads" 12:09:18 Jo: does this inhibit data discovery again? 12:09:39 adam: make it all available as an RSS field? 12:10:06 Jo: load all the data with display:none until script reveals it? 12:10:48 PROPOSED RESOLUTION: Remove 3.5.2 and 3.5.4 and replace with "Avoid Page Reloads" 12:10:55 +1 12:10:58 +1 12:11:00 scribenick SeanP 12:11:11 Scribenick: SeanP 12:11:23 s/scribenick SeanP// 12:13:00 RESOLUTION: Remove 3.5.2 and 3.5.4 and replace with "Avoid Page Reloads" 12:13:58 Jo: We want say something about techniques for what? 12:14:21 ...The best practice is about flipping views. 12:14:43 Adam: We have 3.5.2, avoid page reloads. 12:15:06 ..3.5.2 and 3.5.4 are combined into one BP: avoid page reloads. 12:15:40 ...downside of XHR is that content is not discoverable by Lycos or other crawlers. 12:16:10 ...I'd like someone to devise the right thing to do in this case. 12:16:30 Jo: It's obvious that if you want discoverable content, then you should like to it. 12:16:58 DKA: We're talking about Web Apps here. We're talking about cool apps that may not be indexable. 12:17:05 Jo: It's worth noting however. 12:17:51 s/like/link/ 12:18:16 PROPOSED RESOLUTION: Under new BP Avoid Page Reloads, include a note to the effect that content that is _only_ retrieved dynamically and is not available via links is not discoverable 12:19:01 +1 12:19:04 +1 12:19:08 Jo: Adam, you'd like to add some techniques, right. 12:19:12 +1 12:19:17 +1 12:19:18 +1 12:19:20 Adam: No, I'm fine with just the note. 12:19:34 RESOLUTION: Under new BP Avoid Page Reloads, include a note to the effect that content that is _only_ retrieved dynamically and is not available via links is not discoverable 12:19:59 Jo: 3.5.8, Separate Rarely Used Functionality 12:20:25 Adam: My proposal is replace 3.5.8 with Partition Application Functionality 12:21:23 ...Make this section less technical. If you have a large complex app, chop it up into small parts instead of having a giant JS file. 12:21:31 Jo: Is this a mobile best practice? 12:22:56 Francois: It's not necessarily mobile; if you just need to download a small part of the functionality for your app, then you should do it. 12:23:15 Adam: We see that a lot of the time taken for an app is JS parsing time. 12:23:37 Francois: Could be part of minimize time to first view. 12:24:06 Adam: I'll move it to "minimize time to first view" 12:25:06 Francois: I think we'll have the same discussion on 3.5.9, Enable Progressive Rendering 12:25:26 PROPOSED RESOLUTION: Remove 3.5.8 and take relevant portions of it into new BP minimize time to first view - parsing Javascript being time consuming and resource intensive 12:26:53 +1 12:26:56 +1 12:26:56 +1 12:26:56 +1 12:26:57 +1 12:26:59 +1 12:27:00 +1 12:27:02 +1 12:27:03 RESOLUTION: Remove 3.5.8 and take relevant portions of it into new BP minimize time to first view - parsing Javascript being time consuming and resource intensive 12:27:32 Jo: Moving to 3.5.9 Enable Progressive Rendering 12:28:30 Adam: This may be kind of redundant since it is in other standards docs. 12:28:50 Jo: This can become "Minimize time to first view" 12:29:16 Adam: We can rename it. 12:30:05 Adam: Enable Progressive Rendering is just a bullet point in "minimize start up time" 12:30:15 PROPOSED RESOLUTION: Absorb 3.5.9 into new BP Minimise time to first view as a technique 12:30:33 +1 12:30:35 +1 12:30:38 RESOLUTION: Absorb 3.5.9 into new BP Minimise time to first view as a technique 12:31:27 Francois: We were going to change the title of 3.5.10 to a more general title. 12:32:05 PROPOSED RESOLUTION: Genenralise 3.5.10 to refer to consistency of state across devices for a given user 12:32:17 +1 12:32:37 +1 12:32:44 +1 12:32:47 +1 12:32:49 +1 (and support for calling out Desktop and Mobile as a specific example) 12:33:05 RESOLUTION: Generalise 3.5.10 to refer to consistency of state across devices for a given user 12:33:13 s/Genenralise/Generalise/ 12:34:45 Kai: On 3.5.4, Group closely couple views, it recommends that you hide content. We've played around with that and it makes really large pages. 12:35:02 Adam: I think that section is going to go away. 12:35:52 Kai: On 3.5.1. Design for Multiple Interaction Methods, should we refer to Multi-Modal Interaction Group? 12:36:04 Adam: I think that is different. 12:36:38 DKA: Yes, we're just trying to highlight the focus vs. touch vs. pointer. 12:37:27 Kai: Is the Canvas tag a best practice; I'm not sure. 12:37:56 Adam: A good time to discuss that is when we talk about Jeff's Canvas contribution. 12:38:34 Adam: The next section to discuss is 3.6.3 and 3.6.4 12:39:37 Adam: Eduardo raised the point: A lot of BPs say that we should use XHR, and then we have a BP that says make it works on devices that don't support XHR. 12:40:00 Kai: I don't think it is contradictory; it's just necessary. 12:41:11 Jo: You should try to make a mobile app work on as wide a range of devices as possible. Just because we are recommending web apps doesn't mean that they shouldn't necessarily work on lower class devices. 12:43:31 Bryan: I think we should recommend where important, use discovery techniques to discover the functionality of the device, but we shouldn't say that you have to design a version for the lowest common demoninator. 12:43:48 s/demoninator/denominator/ 12:44:33 Bryan: I could build a web app that has nothing to do with network interaction; which just uses local interaction on the device. 12:44:50 Adam: I think that is my feeling as well. 12:45:15 Kai: Isn't that the same as saying we are relying on class 2 and 3? 12:45:32 Bryan: You should be intelligent to use alternate means. 12:45:53 Kai: You need to classify your devices so you know what to aim for. 12:46:13 Bryan: You need to know what you are aiming for. 12:46:47 http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0104.html 12:47:26 Adam: What has been said today, we seem to feel that these BPs (3.6.3 and 3.6.4) are OK. 12:48:34 Bryan: If you are going to reach the broadest list of devices, you need to use alternate techniques. 12:49:17 DKA: For advanced devices, this doc is applicable; for legacy devices we say use other techniques. 12:49:31 Jo: We are not saying that. 12:50:06 Jo: If you are only developing for the iPhone; is that good practice? 12:50:20 Adam: Depends on the market. We don't develop for some devices. 12:51:24 ...This doc focuses on devices that have platforms that e.g. support JavaScript. 12:51:49 Jo: We also need to deal with JS being turned off, but I suppose that doesn't happen much anymore. 12:52:12 how about to add categorize about class within each statement ? 12:52:18 Francois: Eduardo brought up the point that "typical device" may not be the best way to word it. 12:53:24 Jonathan: I would like to see categories under each class of device. 12:53:54 PROPOSED RESOLUTION: Change "typical configuration" to "example configuration" under 3.6.3 12:54:23 Adam: We're talking about using icons in the document to specify what kinds of devices BPs are target for. 12:54:43 DKA: I think the icons are a great idea; after all they are my idea. 12:54:58 Adam: I agree that the icons are a good idea. 12:55:00 +1 12:55:03 +1 12:55:07 +1 12:55:07 RESOLUTION: Change "typical configuration" to "example configuration" under 3.6.3 12:55:07 +1 12:55:43 Jo: We are using icons to specify the features that the device supports. 12:56:07 Jo: I think it is better to do it feature by feature instead of class by class. 12:56:53 Adam: On 3.6.4 we change the wording from "Possible" to "Appropriate" 12:57:31 Alan: Are people going to understand what "406 Not Acceptible" means? 12:57:45 Adam: Well, it's standard HTTP. 12:58:38 PROPOSED RESOLUTION: Water down the language in in 3.6.4 to recomend providing non Javascript versions rather than "if at all possible" for the reasons already stated in that section 12:58:52 DKA: Can we just provide a link to BP1? 13:00:54 Francois: It's more about the spirit of: don't lock yourselves into a technology that you don't necessarily need. 13:01:26 ...there may be parts of your app that don't need the advanced stuff. I don't think that this translates into a BP, however. 13:02:10 Jo: I think 3.6.4 needs more than just changing "Possible" to "Appropriate" 13:02:35 Bryan: How about changing to "Where necessary and possible"? 13:02:42 q+ 13:03:12 ack me 13:03:14 Adam: I think there is a difference between supporting desktop and mobile and mobile and legacy. 13:04:04 Adam: If we wait a couple of years, all devices will support full internet browsers. 13:04:24 DKA: You could follow all the recommendations in this document and not be mobileOK. 13:05:19 q+ to suggest "Support a non-JavaScript Variant if You Want to Reach the Billions of Potential Users Who Don't have a Whizzy Smart Phone" 13:05:29 Adam: If you have to build an XHTML version of every app, I'm not sure I want to do that because the XHTML version won't get the usage. 13:05:35 q? 13:05:38 ack me 13:05:38 DKA, you wanted to suggest "Support a non-JavaScript Variant if You Want to Reach the Billions of Potential Users Who Don't have a Whizzy Smart Phone" 13:05:40 ack d 13:06:16 Jo: We need to say something like "Don't forget about the devices that don't support advanced apps." 13:06:27 DKA: That's basically what I wanted to say. 13:08:05 PROPOSED RESOLUTION: Water down the language in in 3.6.4 to recommend providing non Javascript versions where it is attractive to reach the billions of users that don't have a smart phone rather than "if at all possible" for the reasons already stated in that section 13:08:18 +`1 13:08:34 +1 13:08:35 +1 13:08:35 +1 13:08:36 +1 13:08:38 zakim, '1 is where your heart is 13:08:38 I don't understand ''1 is where your heart is', Jo 13:08:42 +1 13:08:52 +1 13:08:53 +1 13:08:54 RESOLUTION: Water down the language in in 3.6.4 to recommend providing non Javascript versions where it is attractive to reach the billions of users that don't have a smart phone rather than "if at all possible" for the reasons already stated in that section 13:08:56 +1 13:09:26 Francois: Is "local index" clear to everyone? 13:10:32 DKA: I think it needs expansion to something like "local device repository" or something like that. 13:11:42 Jo: Let's move on to Bryan's comments. 13:11:53 -> http://lists.w3.org/Archives/Member/member-bpwg/2009Mar/0057.html Bryan's latest comments on MWABP 13:14:23 Adam: We've dealt with the first two on 3.1.2 and 3.1.3. 13:15:15 Adam: Bryan refers to BONDI directly, we need to mention it directly in the document. 13:15:30 Bryan: The reference we have to BONDI is not good enough. 13:16:51 Adam: It was hard to visualize an app that didn't use personalization, so it seemed kind of obvious that that's what you need to do to write a mobile app. That's why most of the personalization stuff was removed. 13:17:11 ...We should look at the older version and newer version of the doc side by side. 13:18:12 Bryan: The techniques for personalization for desktop don't work for mobile apps. The developer needs to go learn the techniques somewhere if they aren't in this document. 13:19:15 Adam: There is the aspect of using user id from service providers, which not everyone as access to. 13:19:26 Bryan: That data is widely available. 13:20:17 Jo: The feeling of the group is that using the different user data available through different service providers is not practical for app developers. 13:20:36 q+ to suggest aggregators can provide this function... 13:21:12 ack d 13:21:12 DKA, you wanted to suggest aggregators can provide this function... 13:21:15 Jo: There has been a lot of water under the bridge since this was previously discussed. 13:22:15 DKA: In defense of Bryan's position, my perception is that there are now more options for developers to take advantage of personalization. For example, Bango has something that aggregates this kind of information. 13:22:37 Jo: This has been discussed quite a lot in the past. 13:22:58 DKA: I think things have changed in the last 10 months. 13:23:15 Bryan: I understand Jo's position, but there isn 13:23:15 ACTION: Dan to work with bryan to propose some text on user identification 13:23:15 Created ACTION-920 - Work with bryan to propose some text on user identification [on Daniel Appelquist - due 2009-04-01]. 13:23:47 s/isn/isn't anything in the document right now. 13:24:22 DKA: I think using an aggregator is a mobile thing. 13:24:48 Jo: Next: Bryan's comment on 3.2 13:24:57 [ I note there was a long discussion on login forms with 4 resolutions during a BPWG call following the editorial meeting on MWABP, the result of which is not in the latest draft. See: http://www.w3.org/2009/02/10-bpwg-minutes.html#added01 ] 13:25:40 Bryan: This section talks about JSON data. What are the methods for preserving confidentiality of data? 13:26:59 Adam: Originally we said that you don't always need to use HTTPS, you can use hashed identities. The security team said that HTTPS is not the expensive and using hashed identities was dubious. 13:27:51 Bryan: Security people always say to use a secure connection. This isn't always necessary. 13:28:12 jeffs has joined #bpwg 13:28:13 ...Security people are not always the application developers. 13:28:49 Jo: I don't think we can disregard what the W3C security team said. 13:29:15 Adam: I think I agree with Bryan here. 13:30:39 -Bryan_Sullivan 13:30:39 ...however, I think the safest thing to do, is unless we can find some good reasons to recommend these dubious techniques, what have now is good. 13:30:40 -berners_lee_at_google 13:30:41 Team_(bpwg)10:32Z has ended 13:30:42 Attendees were Bryan_Sullivan, +0207881aaaa, Jo, Francois, Alan, Jonathan, Kai, Adam, Rob, Sean, DKA, berners_lee_at_google 13:31:19 RRSAgent, draft minutes 13:31:19 I have made the request to generate http://www.w3.org/2009/03/25-bpwg-minutes.html francois 13:35:47 zakim, conference code please? 13:35:47 the conference code is hidden, jeffs 14:19:34 zakim, room for 4? 14:19:35 ok, Jo; conference Team_(bpwg)14:19Z scheduled with code 26631 (CONF1) for 60 minutes until 1519Z 14:19:51 zakim, code? 14:19:51 the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Jo 14:20:07 Team_(bpwg)14:19Z has now started 14:20:14 +Bryan_Sullivan 14:20:26 +berners_lee_at_google 14:20:57 ScribeNick: francois 14:28:56 [Debussy interlude] 14:29:35 [not-Debussy-anymore interlude] 14:34:03 BanJo: OK, so... 14:34:04 present+ Eduardo 14:34:52 Jo: Let's resume 14:35:36 adam: 3.3.3.1 and 3.3.3.2 sections 14:35:55 ... I'm fine with Bryan's proposal 14:36:35 Jo: I think that we changed it to "in an inappropriate manner" because we didn't want to be prescriptive. 14:36:44 google has joined #bpwg 14:37:30 s/inappropriate/appropriate 14:37:59 bryan: OK, that answers the problem. 14:38:21 ... but I'm talking about 3.3.3.1 14:38:53 +??P3 14:39:11 zakim ??P3 is jeffs 14:39:37 ... we're not clear as to what constitutes the type of information that should be explained. 14:39:37 hello, on voice now & lurking 14:40:37 ... and mentioning the information doesn't say how users information will be protected. 14:40:51 ... We believe developers need more precise instructions. 14:42:24 ... All the section is about disclosure. 14:44:07 adam: the point is about saying that asking users for accessing their contacts doesn't necessarily allow the application to upload the information to some server. 14:44:50 bryan: 3.3.3.1 is ok. 14:45:17 EdC has joined #bpwg 14:45:28 ... but the server exchange case is not backup-ed by any actionable practice. 14:48:00 jo: in short, both of Bryan's comments imply changes in 3.3.3.2. Are you happy with that, Adam? 14:48:57 ... Bryan's point is to stay that text in 3.3.3.1 needs to be reflected in 3.3.3.2. 14:49:54 adam: I guess I'm questioning how the new wording to 3.3.3.2 adds clarity. 14:50:36 bryan: in many cases, the use of APIs need some kind of confirmation dialog. That's the base. 14:51:07 ... In many cases, the Web application doesn't control the underlying framework. 14:51:41 ... and the underlying framework is handling the trust level access dialog. 14:52:53 PROPOSED RESOLUTION: Add a note along the lines sugegsted by Bryan ref making sure that information about the use of data is made available to the user and noting that the guidance needs to be tailored to how the application interacts with the device on a case by case basis 14:53:19 +1 14:53:27 +1 14:53:34 +1 14:53:35 +1 14:53:39 +1 14:53:42 +1 14:53:43 +1 14:53:43 +1 14:53:47 +1 14:53:48 RESOLUTION: Add a note along the lines suggested by Bryan ref making sure that information about the use of data is made available to the user and noting that the guidance needs to be tailored to how the application interacts with the device on a case by case basis 14:54:09 +1 14:54:12 +1 14:54:14 +1 14:54:59 jo: Moving on to the PIM data icon 14:55:27 bryan: Here, we're talking to a broader set of data than just personal information, e.g. gallery. 14:55:45 adam: sounds reasonable to me, we haven't had a conversation about what the icons should be yet. 14:56:02 PROPOSED RESOLUTION: Change reference to PIM DATA APIs to DEVICE DATA APIs 14:56:16 +1 14:56:19 +1 14:56:20 +1 14:56:20 +1 14:56:24 RESOLUTION: Change reference to PIM DATA APIs to DEVICE DATA APIs 14:56:27 +1 14:56:28 +1 14:57:18 bryan: about 3.4, the current text implies that only resource-oriented issues are important. 14:58:03 adam: on the battery use, without precise figures, I'm not sure. About service cost, it makes sense. 14:58:24 PROPOSED RESOLUTION: Add a reference to battery and cost in the introductory sentence of 3.4 14:58:31 +1 14:58:31 +1 14:58:37 +1 14:58:42 RESOLUTION: Add a reference to battery and cost in the introductory sentence of 3.4 14:58:42 +1 14:58:44 +1 14:58:53 +1 14:58:58 +1 14:59:25 bryan: about 3.4.1.2, the current text only talks about simple compression algorithms. There are more ambitious solutions that can be pointed out. 15:00:06 dan: we already talk about minify in some other part. 15:00:43 jo: how about we extend the note on minification to also include encoding techniques 15:01:08 ... there will be a reference to tokenization in the section anyway 15:02:08 adam: there's another BP about optimizing network requests 15:02:18 achuter1 has joined #bpwg 15:02:25 bryan: if it's covered by another BP, that's fine, but that doesn't seem to be the case 15:03:00 as an side ---- this is also bandwidth dependent. the more bandwidth the less net effect of compression. 15:03:05 achuter1 has joined #bpwg 15:03:10 jo: we're more talking about the number of requests than the size of the requests. 15:03:52 EdC: on the one side, you have semantic-free compression techniques, and on the other side, you have compression techniques specific to the content you're trying to compress. 15:04:08 PROPOSED RESOLUTION: Extend the proposed reference to the meaning of "minify" under 3.4.2 to take account of Bryans coments on EXI and WBXML 15:05:06 adam: I think that BP is specifically about semantic-free compression 15:05:34 jo: I'm proposing the above proposed resolution. 15:06:09 sean: why don't we change the title to "minimize application and data size" 15:07:10 adam: I think that's the idea, yes. 15:07:22 jo: OK, let's take sean's suggestion into account, then. 15:07:30 PROPOSED RESOLUTION: Extend the proposed reference to the meaning of "minify" under 3.4.2 to take account of Bryans coments on EXI and WBXML and change the title to "Minimize Application and Data Size" 15:07:43 +1 15:08:06 +1 15:08:16 +1 15:08:37 +1 15:08:53 +1 15:09:04 [talking about whitespace stripping and the difficulty to maintain the delivered code] 15:09:34 +1 15:10:08 adam: we could say something like use gzip, and don't bother to strip whitespaces 15:10:29 RESOLUTION: Extend the proposed reference to the meaning of "minify" under 3.4.2 to take account of Bryan's comments on EXI and WBXML and change the title to "Minimize Application and Data Size" 15:10:56 why not say "bother to strip whitespaces" 15:12:37 jo: moving on to 3.4.11 15:12:54 adam: we're going to combine the bps as agreed this morning 15:13:33 bryan: my text is the previous text. I find it's clearer 15:13:57 adam: if the WG wants to recommend this, I agree with the text, but I don't think we should recommend that as a BP. 15:14:29 jo: per this morning discussion on minimizing the time to first view, what does it give? 15:16:50 ... How about this: I feel that what Bryan is proposing here is too prescriptive. If you want to reflect different user states, saying that the page should contain all the markup that declares and populates user UI elements is not generic enough. 15:16:52 -??P3 15:18:19 adam: I'm a bit confused. We agreed this morning about revamping these BPs into "minimize time to first view" and I have an action to check with José that it's ok. 15:18:45 jo: bryan, where do you stand? 3.4.11 is to disappear. 15:19:14 bryan: I think previous versions answered the question. Now it doesn't anymore. 15:19:30 jo: we're to remove the question altogether. 15:20:01 [noted that Bryan's comment against 3.4.11.2 now moot as a result of the earlier decision and the action to check with Jose ref his original contribution] 15:20:05 bryan: alright. If there's disagreement with the group on that technique, I'm fine with removing it. 15:22:24 section 3.4.4.2 15:23:15 bryan: again, there was more details in the past 15:23:34 jo: I think that's too detailed a level, actually 15:24:19 ... Let's see if what's written now captures the sense of the former more precise text. 15:24:42 EdC: are there any reference about works, reports about these techniques 15:24:49 adam: not to my knowledge. 15:25:11 EdC: has anybody measured that? 15:25:16 adam: no. It would be great. 15:25:57 dan: in our call for request feedback, we can specifically call out for researches that would validate/invalidate these techniques 15:26:40 adam: there hasn't been community feedback on the past drafts, so we should not expect too much on that front 15:27:11 jo: I think there are examples of examples in this text. It's a level of details that is inconsistent with the rest of the document. 15:28:25 PROPOSED RESOLUTION: On 3.4.4 leave text as is 15:28:28 bryan: OK, there will be room for interpretation of the resulting guidelines. Let's move forward. 15:28:34 +1 15:28:41 +1 15:28:42 +1 15:29:30 +1 15:29:34 +1 15:29:38 +1 15:29:39 +1 15:29:42 RESOLUTION: On 3.4.4, leave text as is. 15:30:33 jo: about push, 3.5.11 15:31:08 bryan: I suggest that the way the section is introduced was better worded in the previous version. 15:31:26 ... The purpose for using push is clearer in the previous version 15:32:21 jo: If I recall correctly, the discussion around this was that the point of access is not restricted to operators, but may include Wi-Fi. 15:33:31 bryan: there's work around providing solutions for this type of use case. Push in general is a way to minimize the need to do do so frequent background requests. 15:34:28 rob: what about waking up the application as opposed to pushing a URI to the browser? 15:35:02 bryan: no, it's a much more broader way of having notifications that is not restricted to the browser. 15:35:16 ... It's very widely deployed 15:35:31 ... It's related to optimizing network interactions. 15:36:16 dan: If we're going to talk about this, we're going to have to talk about how to incorporate text messaging into your web applications. 15:36:31 ... and that's actually a very good way to develop cool applications. 15:36:57 ... but obviously, it only works in the context of mobile network operators access points. 15:37:47 jo: I think it's so caveatted with roaming and yada yada that we'd have a hard time coming up with something useful. 15:38:41 bryan: the "alternative vendor-specific initiatives" sentence, I don't know what that means 15:39:14 jo: I think it was to refer to vendor-specific push methods, e.g. the iPhone. 15:39:58 dan: regardless of whether there is a direct link between receiving a SMS and triggering an action, it could still be part of your application. 15:40:21 adam: then we should talk about sending postcards 15:40:47 dan: I'm referring to many apps I've used that make innovative uses of SMS. 15:41:28 ... [describing a cool existing app based on Zip codes and text messages] 15:41:48 adam: we're talking about other complement technologies 15:42:15 dan: it's something exclusively mobile that enhances the user experience of your mobile application 15:43:03 jo: If we were to say something like "exploit mobile specific methods for initiating web applications and interactions" 15:43:05 Exploit mobile-specifc methods for initiating Web applications and interaction 15:43:26 ... then that could be a BP, but having "use Push methods" isn't. 15:43:44 (e.g. SMS, QR codes, OMA Push, quantum entanglement, etc...) 15:44:19 bryan: push is a technique that has a purpose. 15:45:30 jo: I find it a little difficult that a content provider with a simple application would prefer to send tons of SMS just to reduce the amount of data exchanged on the network. 15:45:43 dan: Can I suggest that we move forward with your suggestion? 15:45:57 s/suggestion?/suggest, Jo? 15:46:53 jo: I think it should replace 3.5.11 15:48:00 PROPOSED RESOLUTION: Change 3.5.11 to "Exploit mobile-specifc methods for initiating Web applications and interaction when appropriate" and include SMS, OMA Push and QR Codes as examples of mobile-specific methods. 15:48:35 Is it worth adding cell broadcasting to the list? 15:48:54 PROPOSED RESOLUTION: Change 3.5.11 to "Exploit mobile-specifc methods for initiating Web applications and interaction when appropriate" and include SMS, OMA Push and QR Codes and cell broadcast as examples of mobile-specific methods. 15:49:14 s/specifc/specific/ 15:50:08 OK we'll drop call and restart bridge 15:50:23 zakim, drop bryan 15:50:23 Bryan_Sullivan is being disconnected 15:50:24 dan: the reason I hesitated on cell broadcasting is that we tried to implement it in Germany, but it didn't work that well for interoperability problems between devices 15:50:25 -Bryan_Sullivan 15:50:38 zakim, drop Berners 15:50:38 berners_lee_at_google is being disconnected 15:50:40 Team_(bpwg)14:19Z has ended 15:50:41 Attendees were Bryan_Sullivan, berners_lee_at_google 15:50:52 zakim, room for 4 for 120 minutes 15:50:52 I don't understand 'room for 4 for 120 minutes', Jo 15:51:08 zakim, room for 4 for 120 minutes? 15:51:11 ok, Jo; conference Team_(bpwg)15:51Z scheduled with code 26631 (CONF1) for 120 minutes until 1751Z; however, please note that capacity is now overbooked 15:51:23 Team_(bpwg)15:51Z has now started 15:51:25 zakim, code? 15:51:25 the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Jo 15:51:25 s/dan: the reason I hesitated on cell broadcasting is that we tried to implement it in Germany, but it didn't work that well for interoperability problems between devices// 15:51:30 +Bryan_Sullivan 15:51:52 +berners_lee_at_google 15:52:14 hello, conf bridge failing 15:52:35 PROPOSED RESOLUTION: Change 3.5.11 to "Exploit mobile-specifc methods for initiating Web applications and interaction when appropriate" and include SMS, OMA Push and QR Codes as examples of mobile-specific methods. 15:52:48 +1 15:52:52 +1 15:52:53 +1 15:52:59 +1 15:53:05 +1 15:53:06 +??P7 15:53:20 zakim, ??P7 is jeffs 15:53:20 +jeffs; got it 15:53:21 s/specifc/specific/ 15:53:22 ACTION: Adam to use latest reference from Bryan when referencing OMA Push 15:53:22 Created ACTION-921 - Use latest reference from Bryan when referencing OMA Push [on Adam Connors - due 2009-04-01]. 15:53:24 +1 15:53:30 bryan: I'm ok with that new resolution. I did provide a better link on OMA push. 15:53:35 +1 15:53:35 back, got 4 more mninutes 15:53:45 RESOLUTION: Change 3.5.11 to "Exploit mobile-specifc methods for initiating Web applications and interaction when appropriate" and include SMS, OMA Push and QR Codes as examples of mobile-specific methods. 15:54:06 http://www.it.rit.edu/~jxs/test/canvas/action910draft.html 15:54:13 http://www.it.rit.edu/~jxs/test/canvas/action910draft.html 15:54:48 jeffs: what I did was try to integrate Jo's feedback in my initial solution. 15:54:52 3.5.12 Use Canvas Tag For Dynamic Graphics 15:55:05 jo: first question is: is canvas sufficiently deployed to be considered a BP? 15:55:10 jeffs: I think so. 15:56:07 ... I tried to get feedback from developers about when you should use what. When you should use canvas, SVG. 15:56:18 ... When you use SVG, content is available to the DOM. 15:56:23 ... When you use canvas, it's not. 15:57:31 jo: sorry I mis-managed the time. We won't be here in two hours. 15:57:43 ... We could come back to the point tomorrow. 15:57:58 s/jo: sorry I mis-managed the time. We won't be here in two hours.// 15:58:26 s/.../jo: 15:58:49 dan: just to be clear. It looks like you're recommending the use of canvas rather than SVG, is that right? 15:59:32 jeffs: it's unlikely that developers are going to need elements that have been drawn for other purpose, yes. 16:00:06 -jeffs 16:00:06 jo: I think we're in danger of a declarative vs. procedural discussion here. 16:00:15 ... Let's come back to that tomorrow. 16:02:02 francois: we may have a problem to have something such as "use canvas" in the spec, in the sense that it really creates a dependency with the HTML5 spec. 16:02:24 kai: I think the main point is about implementations, and there are implementations of canvas already deployed. 16:03:02 dan: I think it's not something that is coming, it's something that people are already using. 16:03:48 kai: the question is, is it being using enough? 16:04:58 dan: the tipping point for me was when I realized that an app deployed by a big company used client-side storage. 16:05:48 ... I think this is the whole point of having the icons. 16:06:40 ... When it comes to canvas, getting away from SVG vs. canvas, if it can be shown that there is good support for canvas, then let's do it. 16:07:49 kai: I just wanted to make sure that we agreed on what we're doing in terms of putting HTML5 in the document. 16:08:26 dan: on that particular discussion, let's sleep on it, we need to get back to that item tomorrow with jeff anyway. 16:08:36 jo: OK, let's address Bryan's remaining points. 16:08:46 jo: on 3.5.5. 16:09:13 bryan: The next 3 should be pretty straight. I think examples would be useful. 16:09:51 adam: I agree. Dan mentioned previously the possibility to have some kind of appendix with code examples, I think that would be useful. 16:10:23 jo: I think this particular point would indeed be good in an appendix. 16:11:11 PROPOSED RESOLUTION: Ref Fragment ID and history - either include an example showing how this works, or find a suitable explanatory text that can be referenced in a non-normative way 16:11:17 +1 16:11:22 +1 16:11:25 +1 16:11:25 +1 16:11:25 +1 16:11:26 +1 16:11:27 +1 16:11:36 RESOLUTION: Ref Fragment ID and history - either include an example showing how this works, or find a suitable explanatory text that can be referenced in a non-normative way 16:13:04 ISSUE: Need example of use of Fragment ID and Brwoser History 16:13:04 Created ISSUE-292 - Need example of use of Fragment ID and Brwoser History ; please complete additional details at http://www.w3.org/2005/MWI/BPWG/Group/track/issues/292/edit . 16:13:30 jo: Section 3.5.10 16:14:00 [agreement on Bryan's comment] 16:14:15 RESOLUTION: Reword to clarify 3.5.10.2 16:14:58 jo: Section 3.6.3 16:15:17 ... We already discussed that point this morning. 16:15:43 PROPOSED RESOLUTION: Under 3.6.3 Call out disabled Javascript as a specific use case for Class 1 16:15:45 +1 16:15:47 +1 16:15:48 +1 16:15:51 +1 16:15:52 +1 16:15:56 RESOLUTION: Under 3.6.3 Call out disabled Javascript as a specific use case for Class 1 16:16:32 -Bryan_Sullivan 16:16:33 Team_(bpwg)15:51Z has ended 16:16:35 Attendees were Bryan_Sullivan, berners_lee_at_google, jeffs 16:21:23 RRSAgent, draft minutes 16:21:23 I have made the request to generate http://www.w3.org/2009/03/25-bpwg-minutes.html francois 16:34:22 ScribeNick: achuter 16:34:23 http://docs.google.com/Doc?id=dhpvgnmn_95cp98m3c4&hl=ko 16:34:46 Topic: Contributions from Jonathan Jeon 16:35:18 JJ: Desirble goals for MWABP 16:35:50 JJ: Propose add new subsection to section 2 16:38:03 JJ: Better security; Compatibility improvement; Improving User Experience; Maximizing Development productivity; Performance improvement; Resource saving 16:39:05 JJ: Add as appropriate these goals under each BP statment in section "Desirable goals of this statment". 16:40:04 JJ: For example, 3.1.1 Use Cookies for Simple Client-Side State: 3.1.1.3 Desirable Goal of this statement: [Improving User Experience], [Better security] 16:41:44 AC: Aren't some of these already captured in higher-level headings? 16:42:22 AC: Maybe better to review our headings. 16:42:42 DA: Tags are the modern way. 16:42:51 JJ: Headings not efficient. 16:43:14 DA: Could make a filtered list. 16:43:55 KS: Wouldn't detract 16:44:18 AC: Don't think it adds anything. Adds complexity. 16:45:46 DA: Positive about proposal as there are BPs that address multiple goals. 16:46:00 SP: Like tags for blogs. 16:46:51 http://www.w3.org/WAI/WCAG20/quickref/ 16:47:52 JR: Can we merge this idea with the categories for flip cards Dom proposed 16:48:16 http://www.w3.org/2007/02/mwbp_flip_cards.html 16:50:18 DA: [compares categories for flip cards with those proposed by JJ] 16:50:50 JR: Needs to be orthogonal to existing structure. 16:51:45 JR: So far only one BP under "Security and privacy" 16:52:02 FD: BP about login forms was dropped at editorial meeting. 16:52:59 -> http://www.w3.org/2009/02/10-bpwg-minutes.html#added01 Discussion on login forms 16:53:30 JR: Needs to avoid repeating existing structure. 16:53:47 AC: Concerned that it would add more compexity. 16:54:04 KS: maybe JJ disagrees with existing headings. 16:54:16 JJ: No. But categories needed. 16:54:27 SP: Maybe remove all the headings and use tags. 16:55:07 KS: Yes, maybe remove headings and have all BPs one after another. 16:57:33 KS: As JJ says, many BPs fall into multiple categories. As AC says, having both could be confusing. 16:59:16 DA: Maybe call for review. 17:00:29 JR: Each person could have their own categorisation. 17:00:49 AC: Would also have capability tags. 17:01:24 KS: would only work with dynamic document. 17:02:27 JR: At minimum JJ's proposal shows that we have not sufficiently considered the classification. 17:02:56 JR: Also that it is a linear document and needs a hierarchical structure. 17:05:16 JR: Need to change the section headings. 17:06:56 ACTION: Jonathan to look at how the existing headings could be improved and to propose classiification groupings that are orthogonal (don't talk about the same things) 17:06:56 Created ACTION-922 - Look at how the existing headings could be improved and to propose classiification groupings that are orthogonal (don't talk about the same things) [on Jonathan Jeon - due 2009-04-01]. 17:07:36 http://docs.google.com/Doc?id=dhpvgnmn_97hhvrdjhn 17:08:21 JJ: Proposal for Widget best Practices 17:09:48 JR: Make references to widgets already in document but no definitive document to refer to. 17:10:12 http://www.w3.org/2008/webapps/wiki/Main_Page#Widgets 17:10:24 JR: There are types of widget that are in scope but others that are not. 17:10:36 DA: Only Web app widgets. 17:11:10 JR: Only HTML+CSS +JS otherwise not in scope. Don't want to broaden scope. 17:12:21 AC: We said that widgets of the type that are in scope are not sufficiently different to warrant special treament. 17:12:41 AC: Presently no widget-specific BPs. 17:14:54 JR: Not keen on seperate widget section. But JJ says new things not in the document at present. 17:16:06 JJ: Propose new references. 17:16:31 JJ: Propose newBP, "Keep the widget simple" purpose immediately apparent to user. 17:16:48 JJ: Propose new BP, "have a license agreement" 17:17:14 JR: True, but not mobile-specific. 17:17:56 JR: Principle is to keep to mobile-specific. 17:18:30 [Read JJ's proposed new BPs on screen] 17:19:57 AC: "Provide visual feedback" already covered. 17:20:29 JJ: "Use larger fonts, buttons and controls" 17:21:23 AC: Already have BP about this. 17:22:32 Rob: User can change font size 17:23:00 EC: Allow user to change font size. 17:23:15 JR: so covered in BP1 under FONT SIZE. 17:23:44 JR: Is issue about pixel density on mobile devices. Needs to be addressed somewhere. 17:27:16 ISSUE: Should there be a Best Practice noting that pixel density on mobile devices is typically greater than desktop? or is BP1 [MEASURES] sufficient? 17:27:16 Created ISSUE-293 - Should there be a Best Practice noting that pixel density on mobile devices is typically greater than desktop? or is BP1 [MEASURES] sufficient? ; please complete additional details at http://www.w3.org/2005/MWI/BPWG/Group/track/issues/293/edit . 17:27:49 s/FONT SIZE/[MEASURES] 17:29:27 JR: Consider again "Widget's purpose should be immediately apparent to user" 17:31:07 JR: Can't really make a BP about it. Can't make it simple enough. 17:31:35 SP: Sometimes want multipurpose widget- 17:34:55 JR: All agree with the intention but is not possible to make a BP from it. 17:35:26 http://docs.google.com/Doc?id=dhpvgnmn_98dqm2nddc 17:36:51 JJ: Propose BP "Periodically update heartbeat mesages" 17:37:08 AC: Valid design pattern, but not mobile-specific. 17:39:50 JR: Hpw does it work with "Back off during periods of inactivity"? 17:40:55 AC: Prefer separate BP. 17:41:05 s/Hpw/How 17:41:58 PROPOSED RESOLUTION: Add a note 3.4.4 ref heartbeats and that some applications require presence notification 17:42:06 +1 17:42:07 +1 17:42:08 +1 17:42:09 +1 17:42:09 +1 17:42:13 +1 17:42:18 +1 17:42:32 RESOLUTION: Add a note 3.4.4 ref heartbeats and that some applications require presence notification 17:44:25 JJ: Not only fragment IDs, can use any URI. 17:44:44 AC: IDs work with Ajax within application. 17:45:06 AC: Make URIs RESTful. 17:46:15 FD: How do you update history with script? 17:46:58 AC: using document.location. Changes hsigtory without causing browser to reload page. 17:47:14 s/hsigtory/history 17:47:47 JJ: Not same point. Is about providing unique URIs. Each application state should have unique URI. 17:49:53 JR: Already covered by exisitng BPs. 17:50:07 -> http://www.w3.org/2009/02/10-bpwg-minutes.html#added01 Login form's discussion 17:50:12 Topic: Login forms BP 17:50:50 FD: Do we agree that the login forms BP should be restored? 17:52:39 ACTION: Adam to review discussion on login forms and resolutions threreto and reinstate text appropriately 17:52:39 Created ACTION-923 - Review discussion on login forms and resolutions threreto and reinstate text appropriately [on Adam Connors - due 2009-04-01]. 17:53:00 [close of meeting] 17:53:08 [meeting adjourned at 1750] 17:53:19 RRSAgent, draft minutes 17:53:19 I have made the request to generate http://www.w3.org/2009/03/25-bpwg-minutes.html francois 17:59:24 rob has left #bpwg 18:00:03 JonathanJ has joined #bpwg 18:20:21 Zakim has left #bpwg 19:44:29 seungyun has joined #bpwg 19:44:35 seungyun has left #bpwg