IRC log of wam on 2009-06-09
Timestamps are in UTC.
- 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