08:29:46 <RRSAgent> RRSAgent has joined #wam
08:29:46 <RRSAgent> logging to http://www.w3.org/2009/06/09-wam-irc
08:29:53 <annevk> annevk has joined #wam
08:29:59 <ArtB> Scribe: ArtB
08:30:05 <ArtB> ScribeNick: ArtB
08:30:14 <ArtB> Scribe: Art, Bryan
08:30:18 <ArtB> Chair: Art
08:30:27 <ArtB> Agenda: http://www.w3.org/2008/webapps/wiki/WidgetsLondonJune2009#Agenda
08:30:34 <ArtB> Meeting: Widgets F2F Meeting
08:30:38 <ArtB> Date: 9 June 2009
08:33:25 <ArtB> Topic: Introductions
08:34:12 <Benoit> Benoit has joined #wam
08:36:15 <Benoit> Benoit has joined #wam
08:37:17 <ArtB> Present: Benoit, Mike, Josh, Jere, Art, Robin, Marcos, AndyB, DanA, David, Laura, Marcin, Bryan, Magnus
08:37:48 <ArtB> AB: Arve had a last minute cancelation and will not attend
08:38:20 <ArtB> AB: registered but not here yet: Paddy, Richard Tibbett, Jonathon, Nick and Ivan
08:41:44 <ArtB> Topic: Confidentiality of Minutes
08:42:17 <ArtB> AB: all of the minutes will be Public
08:42:46 <ArtB> AB: any questions about that?
08:42:52 <ArtB> [ None ]
08:43:39 <ArtB> Topic: Agenda Tweaking
08:44:14 <ArtB> AB: Agenda: http://www.w3.org/2008/webapps/wiki/WidgetsLondonJune2009#Agenda_Items
08:45:51 <DKA> DKA has joined #wam
08:47:30 <ArtB> AB: we will start with P+C this morning
08:47:39 <ArtB> ... talk about high priority issues
08:48:02 <ArtB> ... from 13:00-15:00 today we will talk about Security Model vis-a-vis <access> and the WARP document
08:48:21 <ArtB> Topic: Packaging and Config spec
08:48:48 <ArtB> AB: spec: http://dev.w3.org/2006/waf/widgets/
08:50:00 <ArtB> AB: other than feature and L10N are there other hot topics?
08:50:08 <ArtB> MC: no not really
08:51:14 <mhanclik> mhanclik has joined #wam
08:51:45 <ArtB> AB: Henri's http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0699.html
08:51:56 <ArtB> ... comment about clarifying purpose of feature
08:52:20 <MikeSmith> MikeSmith has joined #wam
08:53:19 <MikeSmith> RRSAgent, make minutes
08:53:19 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html MikeSmith
08:53:30 <ArtB> AB: I think the way we have documented feature in P+C is OK
08:53:57 <ArtB> ... but there are questions about what a UA will do with the data
08:54:14 <ArtB> ... what is our plan to specify the behavior?
08:54:25 <ArtB> Scribe: Art, Mike
08:54:31 <MikeSmith> Scribenick: MikeSmith 
08:54:58 <MikeSmith> ArtB: what work remains to be done for <feature>?
08:55:17 <MikeSmith> Marcos: I don't think anything more needs to be done.. it's specified.
08:55:24 <MikeSmith> ArtB: Anybody disagree with that?
08:55:48 <MikeSmith> Marcos: Biggest impact is on BONDI, so it matters most if it is OK as-is for them.
08:56:03 <MikeSmith> Marcos: I think it meets the BONDI use cases.
08:56:17 <MikeSmith> Robin: If Marcos is OK with it, I'm OK with it.
08:56:35 <MikeSmith> ... I'm happier with use cases that don't require it, because that's more Web-like.
08:57:15 <MikeSmith> David: In the absence of a more proper security model, we still support this.
08:57:41 <MikeSmith> s/Marcos/OMTP/
08:57:58 <MikeSmith> David: We are happy for [the editors] to take the lead on this.
08:58:07 <MikeSmith> Marcin: We just want it to be stable.
08:58:29 <MikeSmith> ArtB: Is OMTP going to extend it after?
08:58:33 <Magnus> Magnus has joined #wam
08:58:49 <MikeSmith> Bryan: We may add some semantics, but we are not planning to add additional attributes.
08:59:27 <MikeSmith> David: If we have a policy mechanism -- some way for regulating user access -- then this element is actually redundant.
08:59:41 <MikeSmith> Marcos: So it really is more of a stop-gap for now
09:00:02 <MikeSmith> ArtB: Anybody else have anything to add on this topic?
09:00:22 <MikeSmith> RRSAgent, make minutes
09:00:22 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html MikeSmith
09:01:22 <MikeSmith> s/some way for regulating user access/some way of regulating access for the user/
09:01:45 <MikeSmith> PROPOSED RESOLUTION: The group agrees that the <feature> element as defined in the LC WD is complete.
09:02:55 <MikeSmith> ArtB: Any objections?
09:02:59 <MikeSmith> [none]
09:03:05 <MikeSmith> RESOLUTION: The group agrees that the <feature> element as defined in the LC WD is complete.
09:03:09 <MikeSmith> RRSAgent, make minutes
09:03:09 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html MikeSmith
09:04:49 <MikeSmith> Marcos: [discussing issue of case sensitivity in localization system]
09:05:05 <MikeSmith> RRSAgent, make logs member
09:05:39 <MikeSmith> [discussion about mailing-list discussions from last couple days]
09:06:41 <MikeSmith> Marcin: [talking specifically about recent BONDI decisions around requestFeature() and widgets vs. Web pages]
09:07:37 <MikeSmith> Marcos: as far as requestFeature(), as this point, it does not exist in the Widgets specs.
09:07:54 <MikeSmith> David: Yeah, we are still just discussing it within OMTP.
09:08:09 <MikeSmith> RRSAgent, make logs member
09:08:54 <MikeSmith> Marcin: [explaining background on submission of BONDI specs for review within W3C]
09:10:04 <timeless_mbp> q+
09:10:08 <MikeSmith> Bryan: One question is: Do we have the ability to author [a document] as both a Web page and a Widget.
09:10:24 <MikeSmith> Bryan: Another question is around dynamically loading.
09:11:08 <MikeSmith> Marcos: I think the DAP WG will be the one that needs to answer that. 
09:11:54 <MikeSmith> timeless_mbp: because of localization and path constraints, currently you won't be able to [drop a widget into a page and have it work]
09:12:00 <timeless_mbp> q-
09:12:59 <MikeSmith> Marcin: In theory, for this case, the widget UA should be behaving conceptually in the same way as an HTTP server.
09:13:54 <MikeSmith> ArtB: What I see is that David announced "we are now down, please review"
09:13:55 <hendry> hendry has joined #wam
09:14:52 <MikeSmith> David: So if it's the view of the WebApps WG that getFeature() is more correctly specified within the DAP WG, then we would follow your lead on that.
09:15:22 <MikeSmith> Marcos: The problem is that it currently seems to make assumptions about a particular architecture.
09:15:31 <ArtB> s/down, please/done, please/
09:16:32 <MikeSmith> Robin: Yes, the feedback you are likely to get from browser vendors is that as currently specified, it does not match with browser architecture, and there are other ways to solve the problem.
09:17:14 <MikeSmith> Marcin: The whole BONDI initiative came about because of need for a "fast standard".. but BONDI operates under many of the same principles as the W3C.
09:18:05 <MikeSmith> Marcin: The expectation is that everything that has been produced by BONDI will be reviewed within W3C... but none of what BONDI has produced thus far is considered a "must".
09:19:18 <MikeSmith> David: so to step back, we don't have DAP yet, so we need a stop-gap in the meantime to address the issue
09:19:33 <MikeSmith> RRSAgent, make minutes
09:19:33 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html MikeSmith
09:19:41 <ArtB> Present+ Richard
09:20:03 <MikeSmith> Topic: Localization
09:25:09 <Benoit> Benoit has joined #wam
09:33:50 <Marcos> Marcos has joined #wam
09:44:21 <MikeSmith> RRSAgent, make minutes
09:44:21 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html MikeSmith
09:45:16 <Bryan> Bryan has joined #wam
09:47:31 <MikeSmith> Scribenick: Bryan 
09:50:28 <Bryan> Topic: Localisation
09:50:34 <ArtB> Jere's comments: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0723.html
09:51:08 <darobin> darobin has joined #wam
09:51:13 <ArtB> P+C ED: http://dev.w3.org/2006/waf/widgets/
09:52:43 <Bryan> Jere: comments were mostly editorial
09:52:55 <ArtB> Macros' response to Jere: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0824.html
09:53:17 <Bryan> Marcos: the main issue was case sensitivity in localisation
09:54:12 <MikeSmith> RRSAgent, make minutes public
09:54:12 <RRSAgent> I'm logging. I don't understand 'make minutes public', MikeSmith.  Try /msg RRSAgent help
09:54:18 <MikeSmith> RRSAgent, make minutes world
09:54:18 <RRSAgent> I'm logging. I don't understand 'make minutes world', MikeSmith.  Try /msg RRSAgent help
09:54:23 <MikeSmith> RRSAgent, make log world
09:54:32 <Magnus_Olsson> Magnus_Olsson has joined #wam
09:56:59 <MikeSmith> RRSAgent, make minutes
09:56:59 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html MikeSmith
09:57:59 <Bryan> Marcos: effectively what we have for localisation is a language list and a list of folders. the algorithm is to do a string match, case sensitively.
10:00:09 <Bryan> Marcos: the solution is to match everything in the local part of a path case-insensitively
10:00:31 <Bryan> Josh: forcing failure for anything other than lowercase is another option
10:01:43 <MikeSmith> q+ to say that forcing failure ultimately risks punishing users for authoring mistakes
10:02:09 <Bryan> Josh: it is easy to write an algorithm than discards anything that does not match with lower case
10:03:32 <Bryan> Marcos: we need to ensure we don't violate ISO specs re case requirements
10:04:22 <Bryan> Robin: we don't need to follow the ISO specs
10:04:57 <Bryan> Josh: the widgets spec is not defining a language code thus we don't have to follow rules for languages
10:08:35 <mhanclik> mhanclik has joined #wam
10:08:41 <mhanclik> mhanclik has joined #wam
10:08:48 <Magnus> Magnus has joined #wam
10:10:03 <Marcos> RESOLUTION: in the spec, we will mandate that language tags for locale folders be in lowercase form (relevant to authors). Only locale folders in lowercase form will be matched by the widget user agent. 
10:10:14 <MikeSmith> q-
10:10:30 <richt> richt has joined #wam
10:10:49 <ArtB> ArtB has joined #wam
10:10:58 <ArtB> RRSAgent, make minutes
10:10:58 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html ArtB
10:11:28 <Bryan> Jere: is it possible to have upper-case folders present anyway, and the sensisble thing is to fold it to lower case and continue
10:11:57 <Bryan> Robin: the sensible thing to do is to discard folders that are non-conformant
10:13:04 <Bryan> Jere: compromise, allow any case as long as it's unique and then treat it as lower case
10:14:02 <Bryan> Robin: in a case insensistive file system, how to handle if the language tag folders are not unique - the easiest is just to kill them
10:15:31 <Bryan> Bryan: what is the downside of ensuring uniqueness and case folding?
10:15:50 <Bryan> Josh: it can cause confusion as the author was expecting one behavior and gets another
10:18:15 <timeless_mbp> DRAFT RESOLUTION: any folder as a direct child of the locales folder whose name is not entirely in lowercase will not be reachable by any means.
10:20:09 <Bryan> David: is there any existing requirement mandating lowercase in the specs?
10:20:40 <Bryan> Josh: there is precedent in other specs to require case sensitive matching
10:21:22 <Bryan> No objections.
10:21:23 <Bryan> RESOLUTION: any folder as a direct child of the locales folder whose name is not entirely in lowercase will not be reachable by any means.
10:21:53 <DKA> DKA has joined #wam
10:21:59 <Bryan> Art: are there still some comments on localisation outstanding?
10:22:16 <Bryan> Jere: some editorial comments, the email exchange is ongoing
10:22:54 <abraun> abraun has joined #wam
10:23:05 <Bryan> Marcos: it was proposed to reshuffle the content which is now done, e.g. the localisation is now in one area. Need to do a read-thru to ensure good flow
10:23:52 <Bryan> Marcos: there's nothing else that is editorial - the question on xml:lang needs to be resolved
10:24:44 <Bryan> Josh: in 5.3 the locale/folder needs to not reference the folder name - it needs to be called "locale folder" or something that makes it clear what we are referring to
10:25:15 <timeless_mbp> not locale folder since that's taken
10:26:25 <timeless_mbp> but locale-folder-name which might reference BCP47 with a prose restriction to lowercase, or a copy of BCP47 with the BNF restricted to lowercase
10:26:52 <Bryan> Marcos: to fix this, we need to change elements of the ABNF if we were to take the language tag from bcp47
10:27:07 <Bryan> Robin: it is better to restrict it in prose rather than ABNF
10:27:26 <Magnus> Magnus has joined #wam
10:27:46 <timeless_mbp> ok :)
10:28:44 <ArtB> ArtB has joined #wam
10:29:12 <Bryan> Jere: the issue raised re xml:lang values being unique, does this come from I18N best practices?
10:32:05 <Bryan> Michael: from HTML5, for authoring we have encouraged people to move away from xml:lang
10:32:34 <Bryan> Robin: that's because HTML4 had a lang tag and there is thus duplication. in our case we are starting from scratch
10:33:57 <Bryan> Robin: for widgets, we define the processing model and it will clarify how to handle the set of xml:lang entries
10:34:03 <Bryan> Marcos: the entries are specified to be in document order
10:34:48 <Bryan> Marcin: does this work related to ITS?
10:35:33 <Bryan> Marcos: it relates since the ITS affects to to handle character sequences
10:36:55 <Bryan> Jere: the issue is resolved since the description will define the handling
10:37:19 <Magnus> Magnus has joined #wam
10:40:01 <Bryan> Marcos: in the 1st example of step 5, we need to make the language sequence consistent, and to ensure what is being ilustrated is correct
10:40:12 <richt> richt has joined #wam
10:43:40 <Bryan> Marcos: the use case is the user has entered the language preferences, and the widget user agent ensures the list of languages is per the spec, and to avoid confusion we need to be clear on how it does that
10:45:17 <Bryan> Benoit: is there a point inthe processing model,  how specific the selected language needs to be 
10:46:06 <Bryan> Marcos: there are those who want a specific dialect over the generic or another dialect
10:46:34 <Bryan> Josh: there are those that would prefer english for example to an unknown dialect of their language
10:48:03 <MikeSmith> RRSAgent, make minutes
10:48:03 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html MikeSmith
10:48:24 <Bryan> Marcos: the question is how to eliminate repetitions/ambiguity in the selected list
10:49:50 <Magnus> Magnus has joined #wam
10:50:18 <Bryan> Josh: the processing should enable e.g. avoidance of random untagged english if another language is preferable
10:51:08 <Bryan> Art: are there any objections to the processing model presented on the screen?
10:51:10 <ArtB> ArtB has joined #wam
10:52:05 <Marcos> Draft Resolution: treat language tags in the order they appear in the UA Locale list, instead of treating them as recommended by BCP47. 
10:52:38 <Marcos> "en-us,en-au,fr,en"
10:52:38 <Marcos> Would become: 
10:52:38 <Marcos> "en-us,en-au,fr,en"
10:53:02 <Marcos> "en-us,en-au,fr"
10:53:03 <Marcos> Would become: 
10:53:03 <Marcos> "en-us,en-au,en,fr"
10:53:35 <Bryan> Josh: the example does not yet quite meet the draft resolution
10:55:48 <Bryan> Art: it's a question for Josh and Marcos to figure out how to word in the spec
10:57:01 <Bryan> Resolution: treat language tags in the order they appear in the UA Locale list, instead of treating them as recommended by BCP47.
10:58:17 <Bryan> Jere: an outstanding issue is the runtime resolution of the resources, we can discuss that later
10:58:43 <Magnus> Magnus has joined #wam
11:14:25 <Magnus> Magnus has joined #wam
11:49:16 <fjh2> fjh2 has joined #wam
11:50:11 <rich_t> rich_t has joined #wam
11:52:52 <ArtB> ArtB has joined #wam
11:53:59 <ArtB> RRSAgent, make minutes
11:53:59 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html ArtB
11:56:00 <ArtB> Scribe+ DanA
11:59:25 <tlr-bbiab> zakim, code?
11:59:25 <Zakim> sorry, tlr-bbiab, I don't know what conference this is
11:59:29 <tlr-bbiab> zakim, this will be webapps
11:59:29 <Zakim> ok, tlr-bbiab, I see IA_WebApps(WidgetsF2F)4:00AM already started
11:59:34 <tlr> zakim, code?
11:59:34 <Zakim> the conference code is 9231 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), tlr
11:59:37 <tlr> zakim, call thomas-781
11:59:37 <Zakim> ok, tlr; the call is being made
11:59:37 <Zakim> +Thomas
11:59:52 <tlr> zakim, who is on the phone?
11:59:52 <Zakim> On the phone I see ??P2, ??P3, Thomas
11:59:55 <tlr> zakim, I am thomas
11:59:55 <Zakim> ok, tlr, I now associate you with Thomas
12:00:10 <tlr> zakim, ??P2 is FrederickOrSteve
12:00:10 <Zakim> +FrederickOrSteve; got it
12:00:15 <fjh2> zakim, ??P3 is fjh
12:00:15 <Zakim> +fjh; got it
12:00:15 <tlr> zakim, ??P3 is SteveOrFrederick
12:00:16 <Zakim> I already had ??P3 as fjh, tlr
12:00:28 <fjh2> zakim,??P2 is stevel
12:00:28 <Zakim> I already had ??P2 as FrederickOrSteve, fjh2
12:00:28 <tlr> zakim, FrederickOrSteve is really SteveLewontin
12:00:29 <Zakim> +SteveLewontin; got it
12:00:48 <fjh2> zakim, mute me
12:00:48 <Zakim> fjh should now be muted
12:00:59 <fjh2> zakim, unmute me
12:00:59 <Zakim> fjh should no longer be muted
12:02:40 <ArtB> Present+ Frederick, Thomas, SteveL
12:03:08 <tlr> zakim, who is making noise?
12:03:08 <darobin> Zakim, who's making noise?
12:03:16 <tlr> zakim, who is on the phone?
12:03:16 <Zakim> On the phone I see SteveLewontin, fjh, Thomas
12:03:18 <Zakim> tlr, listening for 10 seconds I heard sound from the following: SteveLewontin (4%)
12:03:32 <Zakim> darobin, listening for 11 seconds I could not identify any sounds
12:03:58 <darobin> do you see me?
12:04:01 <tlr> darobin, if you could dial into the bridge?
12:04:03 <tlr> zakim, code?
12:04:03 <Zakim> the conference code is 9231 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), tlr
12:04:21 <Zakim> + +44.163.567.aaaa
12:04:30 <tlr> zakim, aaaa is [London]
12:04:30 <Zakim> +[London]; got it
12:08:12 <MikeSmith> RRSAgent, make minutes
12:08:12 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html MikeSmith
12:08:27 <tlr> zakim, mute me
12:08:27 <Zakim> Thomas should now be muted
12:08:54 <MikeSmith> Zakim, who's on the phone?
12:08:54 <Zakim> On the phone I see SteveLewontin, fjh, Thomas (muted), [London]
12:09:47 <DKA> DKA has joined #wam
12:10:04 <DKA> Scribe: Dan
12:10:09 <DKA> ScribeNick: DKA
12:10:28 <richt> richt has joined #wam
12:10:53 <DKA> [back from lunch]
12:11:06 <DKA> Topic: Access Requests Policy
12:11:24 <lewontin> lewontin has joined #wam
12:11:32 <DKA> Art: I'm projecting the June 5 version of the WARP document.
12:12:03 <DKA> Art: We want to use this time to go through this document and solicit comments. One question I'd like to pose is - is there consensus to publish the document as FPWD?
12:12:10 <richt> richt has joined #wam
12:12:17 <ArtB> http://dev.w3.org/2006/waf/widgets-access/
12:12:31 <mhanclik> mhanclik has joined #wam
12:12:39 <DKA> Art: over to Robin for a quick walk-through
12:13:20 <Benoit> Benoit has joined #wam
12:13:36 <Marcos> Marcos has joined #wam
12:13:40 <DKA> Robin: To give some background - this spec defines the access element which was previously in PnC and got dropped out to a separate spec rather than delay PnC.
12:13:55 <MikeSmith> RRSAgent, make minutes
12:13:55 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html MikeSmith
12:13:57 <DKA> Robin: It follows typical structure.
12:14:51 <DKA> Robin: It has a simple model whereby the access grants access within the widget execution scope to certain network resources but anything that is outside the widget executtion scope 
12:15:09 <DKA> ...does not have the same levels of access.
12:16:06 <DKA> Robin: The advantage: it maintains protection to sensitive APIs because you can't communicate across iframe boundaries. etc...
12:16:33 <DKA> Bryan: clarify?
12:16:36 <darobin> darobin has joined #wam
12:17:44 <DKA> Robin: if you have a widget with access to the address book (e.g.) and in a separate context you have  an access element that grants it to load something from a foreign host then this context will not have access to the address book.
12:18:36 <tlr> q+ to note that it *can* communicate, but the widget is able to control that access
12:20:42 <tlr> ack t
12:20:43 <Zakim> Thomas, you wanted to note that it *can* communicate, but the widget is able to control that access
12:21:41 <DKA> Thomas: to clarify - a very limited amount of communication is possible using APIs like post message... you do have cross-origin communication within a browser. But this is tightly controlled by the widget. The important point is that the widget cannot script the iframe and the iframe cannot script the widget.
12:21:44 <timeless_mbp> q+ to verify that the widget can't load javascript:scriptWidget() in the iframe
12:22:17 <DKA> Thomas: This gives us a very well-defined interface and puts relatively strict limits - doesn't give access from the web to "risky" APIs yet.
12:23:05 <DKA> Robin: there's no information leakage unless you've trusted an evil widget.
12:23:45 <DKA> Josh: With an iframe, to a normal user, you can load a javascript URL that executes arbitrary code in the context of that web page.... Assuming the widget will not be allowed to do that.
12:24:22 <DKA> Josh: That code executes in the context of the iframe. It doesn't have access to the widget but it has total access to the iframe.
12:24:32 <DKA> Robin: Yes.
12:24:40 <DKA> Josh: So it's not a very tall wall in that direction.
12:24:48 <timeless_mbp> ack t
12:24:48 <Zakim> timeless_mbp, you wanted to verify that the widget can't load javascript:scriptWidget() in the iframe
12:24:49 <DKA> q?
12:25:24 <DKA> Robin: The rest of the spec is the syntax and the processing model.
12:25:49 <DKA> Robin: There have been two messages so far with editorial comments which I'll apply before we publish.
12:26:04 <DKA> [discussion of the comments from Thomas from today]
12:26:15 <ArtB> TLR's comments today: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0859.html
12:26:59 <DKA> Thomas: Point 3 in my notes - I continue to not be convinced that it's a good idea to build a new model within the widget that contains inline content.
12:27:09 <DKA> Thomas: other points raised are editorial in nature.
12:27:56 <fjh2> q+
12:27:59 <DKA> Thomas: [discusses his additional comments]
12:28:37 <DKA> Thomas: To give an example, the document talks about parsing in document order but this doesn't have anything to do with this specification.
12:29:04 <DKA> Thomas: [suggests compressing the parsing instructions]
12:29:46 <DKA> Robin: WRT point 2. I was thinking that it shouldn't say anything about HTML5 security policy but should just say that it uses the security policy "of the host language being used" which removes the dependency on HTML5.
12:30:04 <DKA> Josh: there are 2 parts that reference HTML5.
12:30:13 <DKA> Art: Any objections to that proposal?
12:30:19 <fjh2> q-
12:30:33 <DKA> Josh: The other HTML5 reference needs to point to some other thing.
12:30:48 <DKA> Bryan: [clarify web application scope?]
12:31:56 <ArtB> [ Discuss "The widget execution scope is the scope (or set of scopes, seen as a single one for simplicity's sake) being the execution context for code running from documents that are part of the widget package. Note that a script loaded from an external URI into a document that is part of the widget is running in the widget execution scope. " ]
12:32:37 <DKA> Bryan: If I load a script off of the Web and I run that within a container that is part of the html page that the widget as defined, is that web scope or widget scope?
12:32:52 <timeless_mbp> q+ to ask if <access uri="http://redirect.example.org"> and a widget has <iframe src="http://redirect.example.org/?http://somethingelse.com"> would be loadable
12:33:01 <DKA> Robin: If the access has been granted by the access element then it is running in the widget context.
12:33:25 <DKA> Bryan: if I load further scripts then those have the same permissions?
12:33:28 <DKA> Robin: Yes.
12:33:37 <DKA> Bryan: Where do we transition to the Web scope?
12:33:52 <fjh2> q+
12:33:56 <DKA> Robin: If you have another document - like an iframe - which has an origin that is not inside the widget.
12:33:56 <claudio> claudio has joined #wam
12:34:09 <timeless_mbp> for my reference, CORS is http://www.w3.org/TR/cors/
12:34:59 <DKA> Robin: The case of bringing in script from the web relys on the access element having granted that access [in the widget context] so subject to the access policy.
12:35:59 <DKA> Robin: A widget can contain multiple documents... All of those documents run within the widget scope. If one of those runs a script from a URI on the web then that script is running in the widget context.
12:38:03 <DKA> Robin: We don't want to constrain the security models for others within this spec.
12:38:16 <DKA> Robin: We don't want to break the Web.
12:39:38 <DKA> Bryan: Suggests inserting a [zzzt zzzt]
12:39:59 <tlr> [awfully noisy call right now]
12:40:32 <darobin> http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0732.html
12:40:32 <DKA> Bryan: Suggests inserting a concrete example in the document to clarify.
12:42:11 <DKA> Frederic: I support having more details in the examples - e.g. the airline flight tracker. If you have a feature that allows access to the camera ...
12:42:52 <timeless_mbp> Zakim: mute [london]
12:43:32 <DKA> ... it talks about feature-enabled APIs in section 2. I assume feature enabled then that feature applies to anything [in that context].
12:43:59 <DKA> Thomas: Any script that can control the widget execution context would have access to that feature.
12:44:18 <DKA> Robin: I will put a specific example in to clarify.
12:45:15 <DKA> Frederic: This is truly for network access and not for anything else (e.g. a URI to a feature).
12:45:36 <DKA> Bryan: A local host URI such as a smartcard web server would be covered.
12:45:37 <DKA> [yes]
12:46:19 <DKA> Robin: Your definition of a network resource is anything with a URI that is referenced by DNS or IP.
12:46:25 <DKA> [agreement]
12:46:30 <DKA> q?
12:46:35 <fjh2> q-
12:46:41 <DKA> ack Josh
12:46:58 <Benoit> Benoit has joined #wam
12:46:58 <DKA> ack timeless
12:46:58 <Zakim> timeless_mbp, you wanted to ask if <access uri="http://redirect.example.org"> and a widget has <iframe src="http://redirect.example.org/?http://somethingelse.com"> would be
12:47:01 <Zakim> ... loadable
12:48:17 <DKA> Robin: If access says it's OK to access foo.com and you load foo.com and it redirects to bar.com.
12:48:43 <DKA> Josh: [advertisement for CORS
12:50:17 <DKA> Thomas: Don't have an easy answer to the redirect question. Not clear that CORS is the answer. The fundamental distinction we have is ...
12:50:48 <DKA> Thomas: [this] could be a huge security hole.
12:50:56 <fjh2> q+
12:51:12 <tlr> s/[this]/just mixing redirects and origin determination/
12:51:40 <DKA> Frederic: We have the asterix which allows access to all assets - could this become a problem?
12:52:14 <DKA> Robin: this was debated before but not everyone was happy with the solutiuon. But if you want to access something like google maps you get a zillion subdomains...
12:52:33 <DKA> Frederic: There's no way to state that intent more explicitly?
12:53:02 <MikeSmith> RRSAgent, make minutes
12:53:02 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html MikeSmith
12:53:20 <DKA> Robin: if you enable foo.com and its subdomains then it could allow access to an IP address in your internal network.
12:53:44 <DKA> [consensus we need to fix dns or something]
12:53:56 <tlr> s/fix dns/fix the web/
12:54:05 <tlr> q+
12:54:32 <fjh2> q-
12:54:34 <DKA> Robin: a user agent would assign an opaque, unique, global identifier to each instance.
12:55:15 <DKA> Thomas: I suggest we leave this open because there is a proposal to assign the same identifier to different widgets if they have been signed with the same cert.
12:55:39 <DKA> Robin: We remain silent.
12:55:47 <DKA> Josh: What about multiple instances?
12:55:55 <DKA> Robin: Currently undefined.
12:56:22 <DKA> Thomas: We don't know right now - probably something we should leave undefined at this time.
12:57:04 <DKA> Thomas: When it comes to local storage they would have to take care of not stepping on eachother's toes. That's the one [problem area I see with multiple instances]
12:58:28 <DKA> s/Frederic/Steve
13:01:05 <DKA> Art: where are we wrt FPWD?
13:01:06 <lewontin> Possible that device access security model might further restrict access beyond same-origin.
13:01:18 <fjh2> I was the speaker asking about making intent more explicit...
13:01:22 <lewontin> This shouldn't affect anything in this spec explicitly.
13:01:27 <DKA> Art: What kind of time-frame are you thinking?
13:01:43 <DKA> Robin: I can do it this week.
13:02:14 <DKA> Art: I'd like to give Robin the freedom to make those changes.
13:02:33 <DKA> PROPOSED RESOLUTION: The WARP document modulo the changes Robin's agreed to make is ready for FPWD.
13:03:32 <DKA> [no objections]
13:03:41 <DKA> RESOLUTION: The WARP document modulo the changes Robin's agreed to make is ready for FPWD.
13:03:55 <DKA> Robin: Short name?
13:04:06 <DKA> Art: My recommendation is widget-access
13:05:34 <DKA> [discussion on what to cover next]
13:07:19 <ArtB> ArtB has joined #wam
13:07:27 <DKA> Topic: URI Scheme
13:07:43 <ArtB> Spec: http://dev.w3.org/cvsweb/2006/waf/widgets-uri/Overview.html
13:08:00 <tlr> http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-uri/Overview.html?rev=1.8&content-type=text/html;%20charset=iso-8859-1
13:08:11 <darobin> http://dev.w3.org/2006/waf/widgets-uri/
13:08:11 <tlr> http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-uri/Overview.html?rev=1.8&content-type=text/html;%20charset=utf-8
13:08:28 <DKA> Art: Over to Robin.
13:08:32 <Marcos> http://dev.w3.org/2006/waf/widgets-uri/
13:08:43 <DKA> Robin: This isn't up to date with the latest edits.
13:09:34 <DKA> Robin: I want to propose that the authority is a string that must be ignored in this version. Paves the path forward for use of signatures in future versions.
13:10:38 <Marcos> Scribe: Marcos
13:10:49 <Marcos> ScribeNick: Marcos 
13:11:27 <ArtB> s/Scribe: Marcos/Scribe+ Marcos/
13:11:27 <Marcos> RB: with the issues listed at the begining, plus a few other things, we have enough to run with for version 1
13:11:32 <tlr> works for me
13:11:41 <tlr> certainly ready for FPWD
13:12:18 <Marcos> JS: what does it mean to ignore the authority? 
13:12:18 <Benoit> Benoit has joined #wam
13:12:41 <Marcos> RB: [gives background on whiteboard]
13:13:46 <Marcos> RB: we started that the Origin was synthetic opaque with a UUID, then ppl complained about the UUID so we got rid of it. So the authority part could be used for other things, like crypto. 
13:14:07 <Marcos> JS: the DOM should not reflect that authority? 
13:14:26 <Marcos> RB: in future versions, we might make use of the authority part 
13:14:54 <Marcos> TR: so my understanding is that, when the URI gets dereferenced, the authority part gets ignored... 
13:15:07 <Marcos> TR: the authority does not carry any semantics right now...
13:15:28 <ArtB> RRSAgent, make minutes
13:15:28 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html ArtB
13:15:32 <Marcos> TR: the idea is just to keep it open for now, so we can do more with it later
13:15:47 <Marcos> RB: Agreed
13:16:20 <Marcos> SL: might need to clarify that in section 4 of the spec  
13:17:02 <Marcos> TR: need clarifications or it's going to be hard to parse
13:17:08 <tlr> 3986
13:17:42 <Marcos> BJ: it still conforms to the URI specification, and the UUID would still be dropped
13:17:52 <tlr> (thinking about this, I was wrong; ignore)
13:17:57 <Marcos> s/BJ/RB
13:18:00 <tlr> (about the character repertoire, that is)
13:18:12 <lewontin> Maybe we want to drop the word "unique" in section 4 since we left open the possibility that multiple instances or multiple widgets might share the same URI
13:18:18 <tlr> +1 to dropping "unique"
13:18:45 <Marcos> JS: I need to read the spec, will try to do that now
13:18:53 <Marcos> JS: have editorial comments 
13:19:13 <Marcos> AB: if we look at the issues at the top of the doc. It seems we have closed a few of those issues
13:19:22 <Marcos> RB: a lot of those are editorial
13:19:49 <Marcos> RB: so unicode, UUID are dropped. Can reference a bunch of things from P&C. And the thing about dig sig, not sure what I meant.
13:20:23 <Marcos> JS and RB discuss some minor issues
13:21:39 <Marcos> AB: It's highly likely we are going to get some feedback once this goes out. So, I'm inclined to push of a FPWD ASAP. 
13:21:45 <Marcos> RB: I can have it ready this week
13:22:00 <Marcos> AB: the question is the, should we agree on a FPWD today? 
13:22:04 <Marcos> RB: I think so
13:22:07 <Marcos> MC: I agree
13:22:39 <Marcos> AB: Robin will make the changes, so I propose to the group that we get a resolution to publish
13:23:47 <Marcos> PROPOSED RESOLUTION: The group agrees to publish a FPWD once changes agreed on during this discussion have been spec'd. 
13:24:47 <tlr> q+
13:25:00 <Marcos> RB and BS discuss synthetic origins
13:25:30 <ArtB> BS: I would like to see a definition of synthetic added
13:25:40 <ArtB> RB: yes, I will add a definition
13:26:17 <Marcos> RB: a lot of people were uncomfortable with widget:// 
13:27:43 <tlr> tlr; think it's a bad idea to have a URI scheme which you can't ever write out in absolute
13:27:56 <tlr> tlr: think it's fine to have authoring guideline that says "relative uri references preferred"
13:28:05 <tlr> tltr: bu also think it's a bad idea to forbid them in the implementation
13:28:10 <tlr> s/tltr/tlr/
13:28:27 <Marcos> BS: if I want to call a local resource, can I pass it a parameter? 
13:29:03 <Marcos> RB: it should work, the javascript could access the relevant document property and access that information
13:29:14 <tlr> q+ to note that the spec doesn't say how query is interpreted
13:29:32 <Marcos> RB: you would not be able to post to a widget URI
13:30:34 <Marcos> JS: when I talked to TR, we agreed that POST would not work for 1.0, but may be something that gets added later
13:30:50 <Marcos> BS: how does this work with HTTP?
13:31:06 <Marcos> RB: there is no relationship to HTTP, it's just a URI
13:32:08 <Marcos> TR: the only thing we define for the URI scheme is how to retrieve files form a packaged, but nothing else. WRT queries, they are ignored, but is reflected in the DOM... but we don't say that right now, but it should say it in the spec
13:32:16 <Marcos> RB: fragments also 
13:32:31 <Marcos> RB: ppl will be surprised if they are not there
13:32:44 <Marcos> TR: query is part of the resource identification 
13:33:10 <Marcos> TR: fragment happens after the uri is dereferenced
13:33:53 <Marcos> RESOLUTIONS: The group agrees to publish a FPWD once changes agreed on during this discussion have been spec'd.
13:34:54 <ArtB> Larry: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0642.html
13:35:14 <Marcos> AB: before we close this topic, I did want to follow up on this topic. Larry sent an email about thismessage
13:35:45 <ArtB> AB: the wiki http://www.w3.org/2008/webapps/wiki/WidgetURIScheme
13:36:02 <Marcos> AB: at some point we were keeping track of all the candidates for URI schemes 
13:36:09 <Marcos> AB: in the wiki
13:36:45 <Marcos> RB: on first reading, it seemed very MIME constrained  
13:36:54 <Marcos> JS: yes, I found the same thing. 
13:37:25 <Marcos> JS reads the abstract 
13:37:46 <timeless_mbp> http://www.rfc-editor.org/rfc/rfc2557.txt
13:37:52 <timeless_mbp> last paragraph, first sentence
13:37:57 <timeless_mbp> This document a) defines the use of a MIME multipart/related
13:37:57 <timeless_mbp>    structure 
13:38:08 <timeless_mbp> -- if the abstract is accurate, then the RFC isn't portable for us
13:38:09 <Marcos> RB: I think we need to deconstruct it and see what is good/bad in there
13:38:19 <timeless_mbp> -- if the abstract is not accurate, then the RFC isn't worth reading
13:38:28 <timeless_mbp> oh, *of first page
13:38:50 <Marcos> ACTION: Send Larry a proper response about "thismessage" and how it relates to Widget URI scheme http://www.rfc-editor.org/rfc/rfc2557.txt
13:38:50 <trackbot> Sorry, couldn't find user - Send
13:39:06 <Marcos> ACTION: Robin to send Larry a proper response about "thismessage" and how it relates to Widget URI scheme http://www.rfc-editor.org/rfc/rfc2557.txt
13:39:06 <trackbot> Created ACTION-353 - Send Larry a proper response about "thismessage" and how it relates to Widget URI scheme http://www.rfc-editor.org/rfc/rfc2557.txt [on Robin Berjon - due 2009-06-16].
13:39:45 <Marcos> RB: from what I read it was _very_ MiME related 
13:40:08 <Marcos> BS: what is the context of this discussion?
13:40:28 <Marcos> JS: the TAG is against creating new URI schemes unless one is REALLY needed
13:41:38 <Marcos> AB: the history here is that we decided we needed a new URI scheme for widgets, but we need to explore the whole landscape to make sure nothing fits. 
13:42:42 <Marcos> RB: I'm happy to discuss this with the TAG
13:42:42 <Marcos> RB: I love the TAG, I'm hoping I will be appointed to it. 
13:43:23 <darobin> MC: I want to chair the AB
13:43:45 <Zakim> -Thomas
13:43:49 <Zakim> -fjh
13:43:51 <Zakim> -SteveLewontin
13:43:57 <ArtB> zakim, bye
13:43:57 <Zakim> leaving.  As of this point the attendees were Thomas, fjh, SteveLewontin, +44.163.567.aaaa, [London]
13:43:58 <Zakim> Zakim has left #wam
13:44:04 <lewontin> lewontin has left #wam
13:44:08 <molsson> molsson has joined #wam
13:44:20 <ArtB> RRSAgent, make minutes
13:44:20 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html ArtB
13:53:37 <MikeSmith> MikeSmith has joined #wam
14:09:36 <Marcos> Marcos has joined #wam
14:26:45 <Benoit> Benoit has joined #wam
14:30:07 <Bryan> hello
14:33:23 <darobin> Scribe+ Robin
14:33:31 <ArtB> ScribeNick: darobin
14:33:47 <richt> richt has joined #wam
14:33:51 <darobin> Topic: P+C
14:34:18 <darobin> AB:Jere, did we finish your comments?
14:34:32 <darobin> JK: I think so yes, waiting on an email from MC for formal acknowledgement
14:34:36 <darobin> MC: will do that
14:34:52 <darobin> JK: do we need that for the DoC? Do I need to say I'm happy?
14:34:54 <darobin> MC: yes
14:35:23 <darobin> JK: not trying to push MC
14:35:30 <darobin> MC: need to make sure I've addressed everything
14:35:48 <darobin> AB: from a process & scheduling perspective LC ends on 19/06, so no specific rush
14:35:56 <darobin> JK: happy to co-ordinate offline
14:36:33 <darobin> AB: that's done
14:36:39 <darobin> AB: anything heard from XML Core?
14:36:43 <darobin> MC: no
14:37:41 <darobin> ACTION: Art to ping XML Core and the XML CG about reviewing our PC LC
14:38:01 <darobin> AB: MWBP was also reviewing
14:38:13 <darobin> ACTION: Art to follow up with MWBP chairs for LC comments
14:38:27 <darobin> AB: Marcin, you've sent several comments
14:38:47 <darobin> AB: do you want to discuss them in the group
14:39:00 <darobin> MH: I think we're handling it on the mailing list
14:39:24 <darobin> MH: I'm not sure who else would speak up about versioning and interoperability
14:39:32 <darobin> AB: I wanted to talk about versioning
14:40:01 <darobin> AB: what is the consensus about versioning for PC — emails trail off but that doesn't mean we have consensus and no issues
14:40:07 <darobin> MC: I think we're fine
14:40:35 <darobin> MC: we have made it as future-compatible as possible based on past experience, on other groups' languages, on their recommendations
14:41:00 <darobin> MC: we think our processing model is solid enough to handle the future
14:41:05 <darobin> RB: I agree
14:41:10 <timeless_mbp> timeless_mbp has joined #wam
14:41:43 <darobin> MH: I think on the mailing list we've agreed that versioning is built on the NS, if there's incompatibility we can change it
14:41:48 <darobin> MH: spec grows monotonically
14:41:57 <darobin> MC: ensure back-compat of new releases
14:42:02 <darobin> s/MC/MH
14:42:18 <darobin> MH: two aspects: 1) the versioning of the format, 2) versioning of the APIs
14:42:25 <darobin> MH: e.g. Geolocation
14:42:55 <darobin> MC: the P+C doesn't concern itself with the APIs
14:43:02 <ArtB> ArtB has joined #wam
14:43:05 <darobin> MC: but in P+C we take the same architectural approach
14:43:15 <darobin> MC: future-compatibility without explicity versioning
14:43:29 <darobin> MC: because you end up with a situation whereby you need to support previous versions, it's heavy
14:43:44 <darobin> MC: lots of legacy crap, like WAP, because there's content out there that uses it
14:43:48 <darobin> MC: we want to avoid that
14:44:06 <darobin> MH: this changes my understanding
14:44:16 <darobin> MH: you want to drop support for some APIs
14:44:36 <darobin> MC: no, we just want to support one evolving API built to be back-compatilble
14:45:04 <darobin> MH: you assume there will be no deprecation
14:45:06 <darobin> MC: yes
14:45:39 <darobin> RB: and if there are breaking changes we change the name — just like for namespaces
14:46:25 <darobin> Magnus: at some point you make changes, how do you determine whether that something has changed without versioning?
14:46:41 <darobin> MC: that approach doesn't work, it doesn't live up to the lifespan that web content has
14:46:54 <darobin> MC: "at least 100 years" is a design principle
14:47:03 <darobin> MC: running the same Tetris a century from now
14:47:19 <darobin> MC: archive.org should still run
14:47:36 <darobin> MC: it's about creating a communication medium that will stay there for a very very long time
14:47:46 <darobin> MC: instead of dying after a few years
14:47:58 <darobin> MC: pages from 1991 still work
14:48:21 <darobin> MH: you don't know it's from 1991
14:48:26 <darobin> MC: and you don't care — which is the point
14:48:52 <darobin> BS: that works as we have a slow transition from one language to another — but you expect applications to change faster
14:49:15 <darobin> Josh: no — on the web we expect things to keep working even if the author is long dead
14:49:17 <darobin> MC: like a dead
14:49:34 <darobin> Andy: I don't expect Betamax to work today
14:49:50 <darobin> Josh: as a user, if it has good content — I want to watch
14:50:15 <darobin> MC: that is a fault in the design of Betamax
14:50:20 <darobin> MC: it's very frustrating
14:50:28 <darobin> RB: and it's a loss to civilisation
14:51:05 <darobin> BS: media conversion occurs all the time — valuable content gets converted
14:51:33 <darobin> MC: we'll still support legacy stuff
14:51:38 <darobin> BS: you mean if possible
14:51:43 <darobin> MC: no, actually support
14:52:04 <darobin> Benoit: a new browser created today would have to be compatible all the way to 19991
14:52:18 <darobin> MC: that's the point
14:52:37 <darobin> BS: in the case of APIs you may find a better way to do it
14:52:42 <darobin> RB: just change the name
14:52:55 <darobin> BS: but then you don't have to support the old ones
14:53:03 <darobin> RB: yes you do, there's content out there
14:53:08 <darobin> MH: versioning helps
14:53:15 <darobin> Josh, MC, Benoit, RB: no it doesn't
14:53:30 <darobin> Benoit: versioning only works if you can decide to support just one version
14:53:39 <darobin> Benoit: or deprecate some versions
14:53:53 <darobin> MH: it depends on the relationship between v1 and v2
14:54:11 <darobin> Benoit: if v2 is very different from v1, it's not v2 — it's something different
14:54:22 <darobin> BS: in principle I agree that back-compat is important
14:54:32 <darobin> BS: but there will be cases when we leave technologies behind
14:54:42 <darobin> BS: I think e.g. SMS will be replaced by SIP
14:55:05 <darobin> MC: people will still want to access them
14:55:12 <darobin> RB: and it's not a publishing format
14:55:18 <darobin> BS: but I'm talking about an API
14:55:40 <darobin> BS: there'll be a new API, but still the old SMS API
14:55:56 <darobin> BS: what if the device doesn't have the capability?
14:56:14 <darobin> Benoit: it's a capability issue
14:57:24 <darobin> RB: that's a capability issue, not a versioning issue
14:57:33 <darobin> MH: what if a browser doesn't implement all the APIs?
14:57:38 <darobin> RB: then it's not very useful
14:58:26 <darobin> AB: can we come back to the P+C spec
14:58:53 <darobin> MC: the @version is only for authors, it only identifies the version of the widget — it's just a string that humans can interpret
14:59:07 <darobin> MH: I wanted to change the name of this attribute
14:59:15 <darobin> MC: it's in line with how it's used
15:00:12 <darobin> MH: it's different from how it is in other W3C specifications
15:00:30 <darobin> AB: let's try to get some closure
15:00:37 <darobin> AB: does anybody object to the definition in the P+C?
15:00:51 <darobin> MC: Marcin, what's your proposal?
15:00:56 <darobin> MH: @widget-version
15:01:10 <darobin> MH: I would like someone from the TAG to review this
15:01:30 <darobin> MH: geolocation also define a version attribute on the object
15:01:32 <MikeSmith> q+ to comment
15:01:39 <darobin> MH: for the specification version
15:01:40 <Zakim> Zakim has joined #wam
15:01:42 <MikeSmith> q+ to comment
15:01:53 <darobin> AB: I don't see a conflict between that and us
15:02:01 <darobin> MC: I can't find that on the API
15:02:15 <darobin> MH: it was discussed today, also with Anne
15:02:39 <darobin> MH: if W3C is a spec vendor, then make it consistent
15:02:44 <MikeSmith> ack MikeSmith 
15:02:45 <darobin> RB: that's already hopeless
15:02:45 <Zakim> MikeSmith, you wanted to comment
15:02:57 <darobin> MS: the TAG is already having a discussion about versioning
15:03:08 <darobin> MS: co-ordination is not a constraint
15:03:43 <darobin> MS: you don't want W3C to attempt to impose coherence at that level of granularity — it would grind everything to a halt
15:04:03 <darobin> AB: we're not going to find authority in the W3C that will tell us what to do
15:04:14 <DKA> DKA has joined #wam
15:04:21 <darobin> MS: the one point in the process where that can happen is during transition
15:04:36 <darobin> MS: at that point a formal objection can raise to the Director
15:04:54 <darobin> MS: and then the Director steps in, having collected information from the TAG
15:05:22 <darobin> AB: we don't want TimBL having to step in with the naming of an attribute
15:06:30 <darobin> Josh: I'm fine with a change to make the text say in its first sentence that @version is the version of the widget, not of anything else
15:07:09 <anne> fwiw, geolocation does not specify version on the object
15:07:10 <heycam> heycam has joined #wam
15:07:25 <anne> it is being considered by some, but that's not the same
15:07:30 <anne> (and I don't think it'll happen)
15:07:33 <darobin> MH: I think that by doing this we are breaking the architectural assumption of W3C specifications
15:07:42 <darobin> MH: elsewhere it is version of the specificaiton
15:07:50 <darobin> MH: seen it in SVG, SML
15:08:04 <darobin> thanks anne
15:08:14 <darobin> MS: that's not true — e.g. HTML
15:09:06 <darobin> RB: note that those examples do not have the same semantics
15:09:38 <darobin> Josh: we shouldn't blacklist a word because it didn't work in other semantics — we want to use it for useful semantics
15:09:55 <darobin> MC: how can we clarify this?
15:10:06 <darobin> JK: it's already clear, I don't see what the confusion is
15:10:12 <darobin> Josh: agreed
15:11:08 <darobin> Josh: I was confused by the attribute type description — can we stick it after boolean, numeric (or alphabetically) so that it doesn't jump out so much?
15:11:09 <darobin> MC: yup
15:11:32 <darobin> AB: third time, does anybody object to the way in which the @version attribute has been defined?
15:11:56 <darobin> [None]
15:12:06 <darobin> RESOLUTION: @version as defined in P+C LC is acceptable
15:12:37 <darobin> AB: any other issues to raise today?
15:12:57 <darobin> MC: thank you Marcin for your feedback, fixed a lot of stuff
15:13:03 <darobin> AB: +1
15:13:11 <darobin> AB: is MaxF going to submit comments?
15:13:17 <darobin> MC: no, Lachlan and Anne are
15:13:58 <ArtB> AB: this one http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0789.html
15:14:51 <darobin> AB: one extra topic, Scott Wilson brought up a number of good things, do we want to discuss some of them or is the on-list discussion enough to make progress?
15:15:15 <darobin> MC: I think we're fine for P+C — a lot of his comments recently have been about A+E
15:15:59 <darobin> AB: I have a cloudy crystal ball
15:16:14 <darobin> AB: modulo any major issues we should be ready to go to CR
15:16:22 <darobin> AB: what's your sense here Marcos?
15:16:37 <darobin> MC: it's hard to judge, the commenters I have lined up may bring up issues
15:17:15 <darobin> MC: I think people on the WG have gone through it, hopefully we've weeded out issues
15:17:30 <darobin> MC: I plan to finish before I go on holiday (18th)
15:17:40 <darobin> AB: Dan, will MWBP review?
15:18:05 <darobin> DKA: hasn't MWBP come back?
15:18:09 <darobin> AB: for LC1
15:18:19 <darobin> DKA: I don't think there'll be any feedback for LC2
15:18:37 <darobin> ACTION: Josh to go through P+C one more time
15:19:19 <darobin> AB: I don't want to get a bunch of comments on the 20th — let's not extend the time, it's been in LC since the beginning of the year
15:19:42 <DKA> +1
15:20:22 <darobin> RB: should we ask the SVG WG to review?
15:20:25 <darobin> Josh: good idea
15:20:41 <darobin> ACTION: Robin to ask the SVG WG to review (before the 19th)
15:20:56 <shepazu> noted
15:21:37 <darobin> Benoit: what does vacation mean for the CR timing?
15:21:56 <darobin> MC: probably July 1st
15:22:22 <darobin> Benoit: can't decide on the 18th
15:22:39 <darobin> MC: back on the 25th
15:22:51 <darobin> MC: I should be able to ring in for the conf
15:23:20 <darobin> AB: we could record a decision to go forward on the 20th
15:23:27 <darobin> AB: using a call for consensus
15:24:11 <darobin> AB: if there are no objections, I'll then send a transition request
15:24:39 <darobin> DKA: we could do it on the 25th's call
15:24:45 <darobin> AB: ok, let's do that
15:24:53 <darobin> RB: I can fix the spec for pubrules if needed in MC's absence
15:25:02 <darobin> MC: and it should be set to go anyway
15:25:06 <darobin> AB: we'll cover testing tomoroow
15:25:36 <darobin> AB: PC, AOB?
15:25:44 <darobin> Josh: exit criteria?
15:25:50 <darobin> MS: what's the plan?
15:26:01 <darobin> MC: I like the XBL2 criteria
15:26:04 <darobin> AB: I like the DigSig
15:26:13 <darobin> MC: it says the same thing, but wishy-washy
15:27:50 <darobin> Josh: I like the second sentence about openness
15:27:57 <darobin> AB: not sure it's clear enough
15:28:26 <darobin> MS: we don't need to overanalyse it, it's just about not getting the spec out based on some in-house implementation that can't be verified
15:28:40 <darobin> MS: needs some degree of distribution and general testing
15:30:05 <darobin> Josh: the DigSig one requires 2 implementations of each test — not of the whole thing. Let's use the XBL2 version
15:30:49 <darobin> AB: if the implementation ships as part of a phone, does it count
15:31:21 <darobin> DKA: yes
15:31:33 <darobin> RB: yes
15:33:29 <darobin> RB: we don't need to overlegalise it, this very same WG will decide when we agree to move out of CR
15:33:35 <darobin> RB: this really is process wonking
15:33:56 <darobin> AB: can we not have the same EC for each spec
15:34:52 <darobin> RB: how about reusing DigSig, but changing two implementations of *each* test but two of *all* tests?
15:35:06 <darobin> RB: it's a two word change
15:35:46 <darobin> [AB summarises the proposal for MC]
15:36:02 <timeless_mbp> ... and demonstrated, according to the test suite, two interoperable implementations.
15:36:54 <darobin> Dave: we could even drop "each test"
15:37:45 <darobin> AB: anybody object to replacing " for each test" with nothing?
15:38:01 <darobin> MC: the XBL2 one is better but I can live with it
15:38:25 <darobin> MC: I have made the change
15:39:06 <darobin> RESOLUTION: the agreed-upon DigSig CR EC will be applied to P+C and to all subsequent specs in this WG
15:40:09 <darobin> Topic: Updates
15:40:47 <darobin> DKA: do we have a PAG call?
15:40:50 <darobin> MS: yes
15:41:44 <darobin> AB: the PAG is having weekly conferences as per process
16:02:16 <molsson> molsson has joined #wam
16:04:08 <darobin> BS: it had to do generally with the purpose for the access element v the feature element
16:04:26 <darobin> BS: there were two things I proposed
16:04:28 <darobin> BS: 1) a @required flag
16:05:03 <darobin> BS: you get only what you declare in the way it is defined, which means that without prior knowledge that a specific domain is going to be allowed, you won't find out until it doesn't work
16:05:14 <darobin> BS: you can't get access to things that may be useful but not essential
16:05:34 <darobin> BS: <feature> was designed around that, but not <access> — which I find is similar in nature
16:05:53 <darobin> BS: you could have alternate approaches if a netres is not available
16:07:02 <darobin> BS: I based access@required on the feature 
16:07:26 <darobin> RB: it's commented out, pushed out to v2
16:07:33 <darobin> BS: why defer?
16:08:13 <darobin> AB: I think the general reason why some of us felt we should put it off is because we hit LC around christmas last year, and we'd like to consider ourselves feature-complete
16:08:26 <trackbot> trackbot has joined #wam
16:08:26 <trackbot> Sorry... I don't know anything about this channel
16:08:26 <trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
16:08:27 <darobin> BS: but WARP has been moved out into a separate spec
16:08:50 <MikeSmith> trackbot, associate this channel with #webapps
16:08:50 <trackbot> Associating this channel with #webapps...
16:08:55 <darobin> BS: is it assumed WARP is near LC?
16:09:08 <MikeSmith> trackbot, bye
16:09:08 <trackbot> trackbot has left #wam
16:09:10 <trackbot> trackbot has joined #wam
16:09:10 <trackbot> Sorry... I don't know anything about this channel
16:09:10 <trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
16:09:12 <darobin> AB: when we made that decision, it was still in PC
16:09:20 <darobin> AB: so does the decision move with it?
16:09:20 <MikeSmith> trackbot, associate this channel with #webapps
16:09:20 <trackbot> Associating this channel with #webapps...
16:09:30 <MikeSmith> trackbot, status
16:09:30 <trackbot> This channel is not configured
16:09:33 <MikeSmith> trackbot, status?
16:09:33 <trackbot> This channel is not configured
16:09:50 <darobin> AB: the idea was that WARP should move at warp speed
16:09:58 <darobin> AB: I suggest that the same rationale applies
16:10:06 <darobin> AB: we don't want any new features
16:10:42 <darobin> MC: I still don't see much use for these attributes, so from Opera's point of view we don't see them as that useful
16:11:05 <darobin> JK: I'm indifferent about @required, but @duration is disconcerting
16:11:43 <darobin> JK: I see a lot of echo of J2ME and the result of that is when these values were used and applied to mutiple different APIs it very quickly turns into excessive prompting
16:12:06 <MikeSmith> trackbot, init
16:12:23 <MikeSmith> trackbot, status
16:12:23 <trackbot> This channel is not configured
16:12:26 <darobin> JK: that's a UX killer — if we bring that into <access> where the granularity is a URL, and you have several of these, you're going to get more prompting, and a dreadful UX
16:12:29 <MikeSmith> trackbot. leave
16:12:37 <MikeSmith> trackbot, leave
16:12:37 <trackbot> trackbot has left #wam
16:12:50 <darobin> RT: I agree, you're implying UX with prompting — we don't want to imply UX, that's an implementation thing
16:13:09 <darobin> MH: consolidation of the prompts?
16:13:15 <MikeSmith> trackbot, associate this channel with webapps
16:13:23 <trackbot> trackbot has joined #wam
16:13:23 <trackbot> Sorry... I don't know anything about this channel
16:13:23 <trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
16:13:27 <MikeSmith> trackbot, associate this channel with webapps
16:13:27 <trackbot> Associating this channel with webapps...
16:13:27 <trackbot> Sorry... I don't know anything about this channel
16:13:27 <trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
16:13:33 <MikeSmith> trackbot, associate this channel with #webapps
16:13:33 <trackbot> Associating this channel with #webapps...
16:13:41 <darobin> MH: this is an important factor
16:13:56 <darobin> BS: the purpose is not to mandate a UI/UX
16:14:21 <darobin> BS: obviously apps have to be designed or vetted to access some features
16:14:33 <MikeSmith> trackbot, status?
16:14:33 <trackbot> This channel is not configured
16:14:34 <ArtB> Bryan's email: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/att-0844/00-part
16:15:03 <darobin> BS: the purpose of this disclosure is not to promote a given security model
16:15:03 <MikeSmith> trackbot, status?
16:15:03 <trackbot> This channel is not configured
16:15:07 <MikeSmith> trackbot, leave
16:15:07 <trackbot> trackbot has left #wam
16:15:10 <darobin> BS: we will eventually have a process of alignement
16:15:16 <trackbot> trackbot has joined #wam
16:15:16 <trackbot> Sorry... I don't know anything about this channel
16:15:16 <trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
16:15:21 <MikeSmith> trackbot, associate this channel with #webapps
16:15:21 <trackbot> Associating this channel with #webapps...
16:15:24 <darobin> BS: we see this process of prompting as essential
16:15:25 <MikeSmith> trackbot, status?
16:15:25 <trackbot> This channel is not configured
16:15:43 <darobin> BS: but this is just like feature@required
16:15:53 <darobin> BS: this is about what the widget needs to be able to do
16:16:15 <darobin> MC: even if @required is going to be useless because the URL might be unavailable
16:16:22 <darobin> BS: but you can still have a policy
16:16:32 <darobin> MC: yeah, but I think it's overkill
16:16:52 <darobin> MC: <access> says what you want to access, and then it might but unavailable
16:17:00 <darobin> MC: so you're already handling that case
16:17:13 <darobin> BS: but the widget won't install
16:17:24 <darobin> RB: we don't say whether the widget gets installed or not
16:17:44 <darobin> MC: you know access@uri
16:18:14 <darobin> MC: if it's not allowed to access something inside the range of URIs, the required doesn't change anything there
16:18:28 <darobin> MC: on feature it's different but I could live with dropping it there
16:18:31 <MikeSmith> action-1
16:18:41 <darobin> errrrr
16:19:05 <darobin> ACTION: RB to send Larry a proper response about "thismessage" and how it relates to Widget URI scheme http://www.rfc-editor.org/rfc/rfc2557.txt
16:19:05 <trackbot> Created ACTION-354 - Send Larry a proper response about "thismessage" and how it relates to Widget URI scheme http://www.rfc-editor.org/rfc/rfc2557.txt [on Robin Berjon - due 2009-06-16].
16:19:16 <darobin> sorry, had to undrop it
16:19:24 <darobin> MC: the request would just fail
16:19:36 <darobin> BS: but with @reuiqred you can check that by policy
16:20:29 <darobin> BS: you could implement APIs on the web represented as URIs much more flexibly, but they should be equal citizen with feature
16:20:51 <darobin> MC: required on feature is a legacy from when we had fallback — this has gone so it could go too
16:21:20 <darobin> RB: if we drop @required on feature we have to go back to LC
16:21:49 <darobin> BS: if you discover incompatibility earlier, you have a better UX
16:22:03 <darobin> Josh: wrong, users get pissed because they can't install the widget that their friend has
16:22:17 <darobin> Josh: if it bails out too early I can't use it
16:22:28 <darobin> Josh: I can show examples of this
16:22:44 <darobin> BS: I would prefer to not even offer that to download based on capability
16:23:00 <darobin> BS: we can do this in PC, or we can do this externally
16:23:15 <darobin> MC: why do we assume that there will be different policies for different devices
16:23:26 <darobin> BS: we do policy per context, in MIDP and native
16:23:33 <darobin> MC: which are very unsuccessful
16:23:44 <dom> dom has joined #wam
16:23:51 <dom> trackbot, associate this channel with #webapps
16:23:51 <trackbot> Associating this channel with #webapps...
16:23:54 <darobin> BS: some people chage, some people don't
16:24:24 <darobin> AB: the more we talk about policy, the more I think it's a DAP problem
16:24:29 <darobin> RB: thank you Art, you'll pay for that
16:24:31 <JereK> +1
16:24:41 <dom> trackbot, status?
16:24:41 <trackbot> This channel is not configured
16:24:48 <dom> ACTION-1?
16:24:48 <trackbot> ACTION-1 -- Doug Schepers to find All Open Issues For DOM3 Events and Update the Specification -- due 2009-03-18 -- OPEN
16:24:48 <trackbot> http://www.w3.org/2008/webapps/track/actions/1
16:24:58 <dom> dom has left #wam
16:25:04 <darobin> AB: I'm not hearing a lot of support within this WG to do it here
16:25:16 <darobin> AB: there's an opportunity to submit furhter comments when FPWD is out
16:25:29 <darobin> AB: WARP isn't in LC, so in theory it's open to features
16:25:41 <darobin> emphasis on theory
16:25:58 <darobin> AB: I recommend ending the discussion now, and discussing when the FPWD is out
16:26:08 <darobin> MC: in the future, there's only ever going to be one policy
16:26:13 <darobin> MC: for all devices
16:26:56 <darobin> RB: developers certainly would prefer that
16:27:08 <darobin> RESOLUTION: Policy gets discussed in DAP
16:27:43 <darobin> MC: we can add it in a separate spec
16:28:24 <darobin> BS: we'd like to avoid the overhead of addiotinal spec
16:28:41 <darobin> Josh: we'd like to avoid the overhead of extra attributes that turn out to be useless
16:28:59 <darobin> the WG opens a bet about the future
16:29:41 <darobin> ADJOURNED
16:30:32 <ArtB> RRSAgent, make minutes
16:30:32 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/09-wam-minutes.html ArtB
16:32:33 <ArtB> zakim, bye
16:32:33 <Zakim> Zakim has left #wam
16:35:31 <JereK> JereK has left #wam
16:36:46 <ArtB> rrsagent, bye
16:36:46 <RRSAgent> I see 6 open action items saved in http://www.w3.org/2009/06/09-wam-actions.rdf :
16:36:46 <RRSAgent> ACTION: Robin to send Larry a proper response about "thismessage" and how it relates to Widget URI scheme http://www.rfc-editor.org/rfc/rfc2557.txt [2]
16:36:46 <RRSAgent>   recorded in http://www.w3.org/2009/06/09-wam-irc#T13-39-06
16:36:46 <RRSAgent> ACTION: Art to ping XML Core and the XML CG about reviewing our PC LC [3]
16:36:46 <RRSAgent>   recorded in http://www.w3.org/2009/06/09-wam-irc#T14-37-41
16:36:46 <RRSAgent> ACTION: Art to follow up with MWBP chairs for LC comments [4]
16:36:46 <RRSAgent>   recorded in http://www.w3.org/2009/06/09-wam-irc#T14-38-13
16:36:46 <RRSAgent> ACTION: Josh to go through P+C one more time [5]
16:36:46 <RRSAgent>   recorded in http://www.w3.org/2009/06/09-wam-irc#T15-18-37
16:36:46 <RRSAgent> ACTION: Robin to ask the SVG WG to review (before the 19th) [6]
16:36:46 <RRSAgent>   recorded in http://www.w3.org/2009/06/09-wam-irc#T15-20-41
16:36:46 <RRSAgent> ACTION: RB to send Larry a proper response about "thismessage" and how it relates to Widget URI scheme http://www.rfc-editor.org/rfc/rfc2557.txt [7]
16:36:46 <RRSAgent>   recorded in http://www.w3.org/2009/06/09-wam-irc#T16-19-05