08:31:59 <RRSAgent> RRSAgent has joined #wam
08:31:59 <RRSAgent> logging to http://www.w3.org/2009/06/10-wam-irc
08:32:04 <ArtB> ScribeNick: ArtB
08:32:08 <ArtB> Scribe: Art
08:32:12 <ArtB> Chair: Art
08:32:17 <ArtB> Date: 10 June 2009
08:32:24 <ArtB> Meeting: Widgets F2F Meeting
08:32:44 <ArtB> Agenda: http://www.w3.org/2008/webapps/wiki/WidgetsLondonJune2009
08:33:13 <ArtB> Present: Benoit, Mike, Josh, Jere, Robin, AndyB, Marcos, DanA, David, Laura, Marcin, Magnus
08:33:13 <MikeSmith> trackbot, status?
08:33:13 <trackbot> This channel is not configured
08:33:26 <abraun> abraun has joined #wam
08:33:32 <ArtB> trackbot, associate this channel with #webapps
08:33:32 <trackbot> Associating this channel with #webapps...
08:33:39 <MikeSmith> trackbot, status?
08:33:39 <trackbot> This channel is not configured
08:33:49 <MikeSmith> ArtB: trackbut is confused
08:33:50 <ArtB> RRSAgent, make minutes
08:33:50 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/10-wam-minutes.html ArtB
08:35:05 <drogersuk> drogersuk has joined #wam
08:35:07 <Marcos> Marcos has joined #wam
08:35:55 <ArtB> Scribe+ David
08:36:16 <ArtB> Topic: A+E spec
08:36:37 <ArtB> ScribeNick: drogersuk
08:37:20 <mhanclik> mhanclik has joined #wam
08:39:09 <drogersuk> AB: Agenda is API and Events
08:39:24 <drogersuk> ..we have several red block issues
08:39:32 <drogersuk> ...and there is a discussion related to storage
08:40:21 <JereK> JereK has joined #wam
08:41:16 <Marcos> http://dev.w3.org/2006/waf/widgets-api/
08:41:26 <Benoit> Benoit has joined #wam
08:43:23 <drogersuk> MC: To progress this, viewMode is not a big issue here
08:43:46 <drogersuk> AB: Let's go back to the start of the document. Is the abstract up-to-date?
08:44:22 <drogersuk> AB: The title includes events but there aren't a whole lot of events
08:44:29 <drogersuk> MC: There are events
08:44:46 <drogersuk> JS: 3rd bullet point in abstract doesn't make sense
08:45:10 <drogersuk> MH pointed out some editorial issues in the abstract
08:45:59 <drogersuk> ...defined by... defines for example
08:46:56 <drogersuk> JS: requests in the 4th bullet should be request
08:47:23 <drogersuk> AB: What is the interface that supports the last bullet? hasFeature()?
08:47:28 <drogersuk> MC: Yes
08:47:50 <drogersuk> MC: Perhaps we should concentrate on some of these issues rather than the editorial points
08:48:02 <drogersuk> AB: Are there any definitions we are missing?
08:48:08 <drogersuk> AB: In section 4
08:48:24 <drogersuk> ...we've talked about nailing down origin
08:48:54 <drogersuk> MC: it isn't really relevant in this spec, because origin pertains to the storage interface and that already defines where you get origin from
08:49:11 <drogersuk> AB: So we can have this discussion when we discuss the storage attribute
08:50:33 <drogersuk> MC: As long as we have consensus in the group that each widget has its own storage and that storage cannot be accessed by other widgets..
08:50:53 <drogersuk> AB: We'll deal with this as we get to it in the document
08:52:43 <drogersuk> AB: Section 5 begins with the block of the widget interface...
08:53:03 <drogersuk> JK: We need to define what is a feature etc.
08:54:02 <drogersuk> MC: Do we need a more technical definition than P&C?
08:59:05 <drogersuk> There was a discussion about how to define feature
09:00:05 <darobin> http://www.w3.org/TR/SVG11/struct.html#SwitchElement
09:00:25 <darobin> actually, this better: http://www.w3.org/TR/SVGMobile12/struct.html#SwitchElement
09:05:25 <annevk> annevk has joined #wam
09:07:18 <drogersuk> drogersuk has joined #wam
09:07:30 <drogers> drogers has joined #wam
09:08:03 <drogers> AB: Back to section 4 - let's look at the first red block
09:08:39 <timeless_mbp> We considered offering a video decoder as another example of a "feature" in addition to an API. While we decided not to list it as an example, this isn't because it isn't an example, but merely because we decided not to list a second.
09:11:02 <drogers> MC: The first red block item covers some items that are not defined - e.g. viewMode
09:11:43 <drogers> ...viewMode should be in the window modes spec which is not written
09:12:03 <drogers> AB: Robin agreed to be the editor of this
09:12:21 <drogers> ...obviously Robin has had higher priorities
09:13:13 <drogers> AB: mediaquery and windowmodes were going to be two specs
09:13:20 <drogers> MC: and I think they should be one
09:13:39 <drogers> AB: We don't want a dependency on the CSS working group
09:13:58 <drogers> MH: This is a question of timeline
09:14:28 <drogers> AB: So what is the consensus?
09:15:42 <drogers> It was agreed that there would be one spec for this
09:16:19 <drogers> RESOLUTION: There will be one specification for windowmodes and mediaquery
09:17:32 <drogers> MC: We need to align the attributes with the steps to remove the next red block
09:18:31 <drogers> 5.1 - viewMode attribute:
09:20:10 <drogers> in mediaquery spec - feature is defined too
09:20:32 <drogers> ...we need an explanatory note here
09:20:52 <richt> richt has joined #wam
09:22:36 <ArtB> Present+ Kai
09:23:35 <drogers> MC: The text does not make sense
09:23:55 <drogers> <drogers writes z version on whiteboard>
09:25:03 <drogers> MC: The user agent makes the decision about the window mode display
09:25:23 <drogers> ...it is described in the P&C spec (lifecycle) and also in the windowmodes spec
09:26:10 <drogers> AB: The sentence: "Upon instantiation...." was removed#
09:27:34 <drogers> The red block issue: this is a computed value was edited to change to editorial note. It is to be dealt with by the Editor
09:28:16 <drogers> Locale attribute was discussed
09:29:42 <drogers> MC: I don't think this has relevance anymore
09:29:48 <drogers> BS: This could be useful
09:29:59 <drogers> JS: You would want the widget to see everything though
09:30:17 <drogers> ..this definition is currently wrong and unhelpful
09:31:06 <drogers> MC: We will return the user agent locales
09:31:28 <Bryan> Bryan has joined #wam
09:38:02 <abraun> abraun has joined #wam
09:38:14 <abraun> Noting for drogersuk
09:38:31 <abraun> MH: Why is it identifier and not id
09:39:01 <abraun> MC: Because of potential confusion around XML id
09:39:23 <abraun> RB: ok to move identifier to id because their will not be confusion with XML id
09:39:32 <abraun> MC: ok
09:40:59 <abraun> MC: will change width and height to postive numbers.
09:41:11 <abraun> AB: good change
09:43:55 <abraun> MH: authorInfo why not author.info
09:44:51 <abraun> abraun: Josh: each dot adds a lot of overhead.
09:45:06 <abraun> BS: why not just author
09:45:22 <abraun> MC: ok
09:46:28 <MikeSmith> MikeSmith has joined #wam
09:47:46 <abraun> dicussion leads to question Do we need to define installation vs instantiation in P&C?
09:48:41 <abraun> more discussion....
09:49:21 <abraun> AB and Josh prefer definition in A&E
09:49:49 <DKA> DKA has joined #wam
09:50:00 <abraun> MC disagrees
09:52:21 <darobin> http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0445.html
09:53:30 <abraun> AB: where less important than that it is done and is consistent
09:54:41 <abraun> general concern about scope creep delaying P&C
09:56:26 <abraun> ACTION: Marcos to define installation and instantiation 
09:56:26 <trackbot> Created ACTION-355 - Define installation and instantiation  [on Marcos Caceres - due 2009-06-17].
09:57:24 <abraun> AB: wonders if other w3c spec define these
09:57:47 <abraun> MH: may have something in BONDI lifecycle document
09:58:49 <abraun> ACTION: Mhanclik to investigate definitions of installation instantiation in BONDI work 
09:58:49 <trackbot> Created ACTION-356 - Investigate definitions of installation instantiation in BONDI work  [on Marcin Hanclik - due 2009-06-17].
10:16:30 <ArtB> RRSAgent, make minutes
10:16:30 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/10-wam-minutes.html ArtB
10:16:49 <ArtB> RRSAgent, make log Public
10:16:56 <ArtB> RRSAgent, make minutes
10:16:56 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/10-wam-minutes.html ArtB
10:20:58 <richt> richt has joined #wam
10:30:54 <ArtB> ScribeNick: abraun
10:34:47 <Zakim> Zakim has left #wam
10:37:37 <abraun> continued discussion on installation vs instantiation 
10:38:04 <Marcos> Installation means the first time a widget package and the configuration document have successfully passed through the steps for processing a widget package. 
10:38:04 <Marcos> Instantiation is any subsequent run through the steps for processing a widget package post installation of a widget.
10:39:59 <abraun> MC: when you install you set preferences. 
10:40:22 <abraun> AB: why is install only first time
10:41:59 <abraun> BS: I took installation means creating something new rather than restarting the first time
10:46:40 <hendry> postinst and package life cycle is kinda defined by debian. e.g. 'postinst' in http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html
10:47:07 <abraun> MC: intialization is the first time for setting prefs etc
10:48:49 <abraun> Josh: yes, then intiatiation is for making multiple copies
10:49:02 <timeless_mbp> s/int/init/ ?
10:49:15 <timeless_mbp> err no... someone else fix that line in the minutes :)
10:50:03 <abraun> timeless fix the line?
10:50:18 <timeless_mbp> intiatiation => initiation ?
10:50:28 <timeless_mbp> intialization => initialization
10:52:08 <abraun> AB: group has agreed to change instantiation to initialization
10:52:26 <richt> have we lost zakim or this is deliberate?
10:52:36 <timeless_mbp> zakim said it wasn't needed and left
10:52:45 <timeless_mbp> MikeSmith: any idea if this was a time expired thing?
10:53:06 <Zakim> Zakim has joined #wam
10:56:46 <abraun> working through the spec to investigation individual instances of instantiation 
10:57:17 <abraun> s/investigation/investigate/
11:00:59 <abraun> MH: how do instantiate a file
11:02:22 <abraun> MH: has issues with authorHref name
11:03:35 <MagnusO> MagnusO has joined #wam
11:03:38 <abraun> Josh: Link is better than Href
11:05:42 <abraun> AB: should have compelling reasons for change this late in the game
11:06:52 <abraun> MC: won' change P&C because it is substantive
11:07:46 <abraun> agreed that authorHref will remail as is in A&E
11:12:29 <abraun> AB: authorEmail will also remain as is
11:14:30 <abraun> BS: is 5.8 description limited in content? can it have markup?
11:14:54 <abraun> MC: yes but will be stripped out as defined in P&C
11:17:43 <abraun> BS: so I can put a URI in description?
11:20:54 <abraun> Minutes reFlect no additional comments on 5.10 5.11
11:21:06 <ArtB> RRSAgent, make minutes
11:21:06 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/10-wam-minutes.html ArtB
12:14:18 <Marcos> Marcos has joined #wam
12:17:00 <ArtB> Scribe+ Jere
12:17:07 <ArtB> ScribeNick: JereK
12:17:24 <ArtB> Topic: A+E spec - again ...
12:18:43 <mhanclik> mhanclik has joined #wam
12:19:38 <JereK> AB: A&E, preferences. Lots of discussion in the past, strong feelings.
12:19:48 <JereK> ... related to HTML5 storage. Red block.
12:19:57 <MagnusO> MagnusO has joined #wam
12:20:03 <JereK> ... Arve has commented about this. Marcos, lead us.
12:20:47 <JereK> MC: Red block added by me based on input by Hixie. Need to define error conditions when setItem called for read-only
12:21:11 <JereK> ... In context where you already have strorage, must not end up with two.
12:21:20 <JereK> s/strorage/storage/
12:22:04 <JereK> JS: Let's look at section 3.4.
12:22:35 <JereK> MC: It's not there anymore, in separate spec now.
12:22:55 <JereK> BS: Diving into storage now?
12:22:58 <ArtB> Web Storage spec: http://dev.w3.org/html5/webstorage/
12:23:12 <JereK> JS: No, but how you reference it.
12:23:17 <Marcos> http://dev.w3.org/html5/webstorage/
12:23:36 <JereK> BS: Either local or remote storage?
12:23:40 <JereK> JS: Just about the binding.
12:24:04 <JereK> ... Want to have something like in HTML5.
12:24:18 <JereK> BS: Clone this section from HTML5?
12:24:21 <JereK> JS: Yes
12:24:49 <JereK> BS: So not reference? By cloning this section into A&E, not going to reference?
12:25:00 <JereK> JS: No, still going to reference.
12:25:28 <JereK> AB: Josh, what parts?
12:26:10 <JereK> JS: Not the 3rd para, or at least very different. Take first two sentences, refer to widget.
12:26:30 <JereK> ... must have a set of preferences for each instance.
12:27:05 <JereK> ... fourth thing not needed.
12:28:12 <JereK> Noted that Marcos should do this as Josh describes in detail.
12:29:16 <JereK> JS: Do people want to listen to preferences change events?
12:29:55 <JereK> ... some version of para #6 is maybe needed.
12:30:43 <JereK> (Marcos proceeds to read the para/sentence.)
12:31:01 <JereK> MC: Yes, we expect that.
12:32:44 <JereK> MH: Do I need to read HTML5 to understand A&E?
12:32:54 <JereK> MC: Have to solve mutex problems anyway.
12:33:00 <JereK> JS: Do we have workers?
12:33:04 <JereK> MC: Yes.
12:33:15 <JereK> AB: Impl. detail?
12:33:35 <JereK> JS: Workers preempt mutexes?
12:35:01 <JereK> MC: Significant amount of work required.
12:35:17 <JereK> ... not super-difficult, though.
12:35:51 <JereK> AB: What will you have to copy?
12:36:21 <JereK> MC: Preferences and read-onlyness...
12:36:39 <JereK> MH: Could be done consistently in DAP; similar stuff defined in BONDI now.
12:36:51 <JereK> RB: Storage already defines exception codes.
12:37:14 <JereK> ... would use the same set of codes.
12:38:31 <JereK> MC: super simple hash map
12:39:00 <JereK> ... only defines quota error and index size error
12:40:03 <JereK> AB: Important to nail this down, identify the parts.
12:40:40 <JereK> ... almost like defining a profile of Storage.
12:41:23 <JereK> JS: removeItem also has to be able to throw read only error.
12:41:59 <JereK> ... in addition to setItem.
12:42:22 <Marcos> If setItem() or removeItem() is invoked with a value defined as read-only, then the user agent must throw a NO_MODIFICATION_ALLOWED_ERR exception.
12:46:20 <JereK> (live editing of relevant text parts)
12:48:36 <JereK> BS2: First ever instantiation?
12:49:58 <JereK> (Discussion about installation - instantiation comes up again... waiting for the outcome)
12:52:37 <JereK> MC: Not yet satisfied, but might leave that as impl detail.
12:53:07 <JereK> JS: Can we have an "unConfigured" widget instance?
12:55:10 <JereK> AB: People can still submit comments if we go with what we now have.
12:55:25 <JereK> ... All relevant parts copied from WebStorage now?
12:55:27 <JereK> MC: Yes
12:55:46 <JereK> AB: Any other comments? (No.) Moving on to 5.13.
12:56:15 <JereK> ... No feedback. Moving on to 5.14 (hasFeature method).
12:56:28 <JereK> MC: Do we need this?
12:56:52 <JereK> ... no means of requesting a feature.
12:57:45 <JereK> JS: Cheaper for impl, easier on the user to just use it and deal with any errors.
12:59:08 <JereK> MH: Not returning objects anymore. You request a feature and set up a callback.
12:59:26 <JereK> ... not in global namespace.
12:59:46 <JereK> JS: hasFeature needs to die.
13:01:04 <JereK> MH: Similar discussion on geolocation list.
13:01:28 <JereK> AB: Anybody object to deleting 5.14?
13:02:00 <JereK> BS: Didn't see that coming.
13:02:37 <JereK> AB: Marcos, is this harmful?
13:02:41 <JereK> MC: No, just useless.
13:03:04 <JereK> AB: Some people find it useful. Anyone else object?
13:03:37 <JereK> BS2: How can a developer, in a generic sense, find out if something is available?
13:03:50 <JereK> JS: You check for objects, and use them if they are available.
13:04:12 <JereK> ... Object needs to be defined.
13:04:26 <MagnusO> MagnusO has joined #wam
13:05:24 <JereK> MC: Scott Wilson's e-mails re: "What does it mean to have an unavailable API?"
13:05:47 <ArtB> ... http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0712.html
13:06:42 <JereK> MH: hasFeature is about access to config.xml
13:07:02 <JereK> ... if something is required and it's not there, the widget is not instantiated
13:07:10 <JereK> MC: Does not tell you everything
13:07:40 <JereK> JS: You always only get information you already know from hasFeature.
13:08:39 <JereK> AB: If we do keep it, red block issue remains.
13:09:48 <JereK> MC: Deleted the red block.
13:09:59 <JereK> JS: Need to add that the URI needs to be an exact match.
13:10:05 <JereK> MC: No point in adding if we kill it.
13:10:25 <JereK> AB: Could explicitly identify it as a feature at risk.
13:10:25 <Zakim> Zakim has left #wam
13:11:15 <JereK> MC: requestFeature as described before could work, but seems like a mobile optimization
13:11:39 <JereK> MH: Same thing could happen on desktop.
13:11:47 <JereK> MC: Should be discussed in DAP.
13:11:51 <JereK> JS: +1 to MC
13:12:51 <JereK> MC: Better bound to the window object.
13:13:04 <JereK> MH: Affects security.
13:13:27 <JereK> JS: widget isPropertyOf window
13:14:40 <JereK> MH: About window.widget.hasFeature or window.hasFeature?
13:14:55 <JereK> ... would drop hasFeature and deal with it later
13:15:10 <JereK> s/deal with it/deal with requestFeature/
13:17:32 <JereK> AB: When Bryan comes back we'll have a formal vote and a decision.
13:17:44 <JereK> ... On to 5.15, openURL
13:17:48 <Bryan> be there in a minute
13:18:25 <JereK> JS: Need someone to have a veto
13:19:01 <JereK> AB: any objections to 5.15?
13:19:08 <JereK> MC: It is a SHOULD
13:19:23 <JereK> JS: And failure case is a MUST
13:20:36 <JereK> MC: adds statement about UA rejecting
13:20:54 <JereK> JS: can live with it
13:21:07 <JereK> AB: any additions to modfications?
13:21:15 <JereK> ... none, accepted.
13:21:51 <JereK> AB: Back to question about deleting 5.14
13:22:07 <JereK> BS: Some other means to do the same thing?
13:22:35 <JereK> AB: Yes, as DAP gets going they'll look at both {has/request}Feature use cases.
13:23:07 <JereK> RESOLUTION: hasFeature() will be removed from A&E
13:23:33 <ArtB> RRSAgent, make minutes
13:23:33 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/10-wam-minutes.html ArtB
13:24:19 <JereK> AB: Just two more pieces to go with A&E
13:25:24 <JereK> BS: About openURL, assumption about response?
13:25:43 <JereK> JS: No feedback, worth noting?
13:26:32 <JereK> BS: Not returning any data?
13:26:37 <JereK> JS: Yes, it's void.
13:26:49 <JereK> BS: Only argument is URI, no limitations?
13:27:02 <JereK> MC: Yes, openly defined.
13:27:20 <JereK> AB: On to 5.16, getAttention() (basically a prompt)
13:27:44 <JereK> ... Any objections to the current text?
13:28:35 <JereK> ... None noted.
13:28:46 <JereK> ... On to 5.17, showNotification()
13:28:58 <JereK> BS: Is string just plain text?
13:29:49 <JereK> JS: 3rd argument applies it is not modal
13:30:07 <JereK> ... text is subOptimal
13:30:55 <JereK> AB: If UA posted this with title, would there be something to click to make it go away?
13:31:05 <JereK> JS: Yes, but widget won't know when it happened.
13:31:52 <JereK> BS2: iPhone notification example
13:32:33 <JereK> (discussion of how the iPhone applications notify the user)
13:34:10 <JereK> AB: Kai, how would you test user ack?
13:35:15 <JereK> MH: WebIDL for this has issues
13:35:48 <JereK> MC: Should get rid of this, to specify elsewhere to get a more complete notification model
13:36:26 <JereK> AB: +1 to MC. Any other approaches?
13:36:37 <JereK> JS: Feature at risk would be a good baseline
13:37:00 <JereK> AB: Strong feelings about the options?
13:37:06 <JereK> MC: Have to talk to Arve
13:37:44 <JereK> AB: MC will mark it as at risk of being removed.
13:38:55 <JereK> JS: Draws analogy to Growl notifications
13:39:40 <JereK> MH: Security workshop Dec 2008: Mozilla and async prompts. Is showNotification part of this effort?
13:40:56 <JereK> JS: If doing that, there is overlap. Sync notifications eat up stack.
13:41:47 <JereK> ... If Windows would have that, it would be duplicated.
13:42:39 <JereK> AB: Want to close discussion about A&E
13:43:10 <JereK> MC: References already done.
13:43:26 <JereK> AB: OK to remove red block then?
13:43:32 <JereK> MC: Yes.
13:44:00 <JereK> AB: Publication plan of A&E?
13:44:06 <JereK> MC: Needs a day of TLC
13:45:04 <abraun> abraun has joined #wam
13:45:07 <JereK> AB: Is the next pub a WD or LC?
13:45:35 <JereK> ... Any objections for the next version being a LC?
13:45:39 <JereK> ... None recorded
13:45:54 <JereK> ... When do we record a resolution that it is ready for LC?
13:46:32 <JereK> ... Propose to publish LCWD with Marcos' changes, ASAP
13:47:23 <JereK> ... Earliest pub date most likely June 18th, needs to be ready by June 16th
13:47:33 <anne> http://www.w3.org/TR/widgets/ is going to LC again?
13:47:53 <JereK> MC: Want to finish P&C first, comments from Marcin
13:47:59 <MoZ> MoZ has joined #wam
13:48:36 <Marcos> anne, no
13:49:03 <JereK> AB: Agree to publish LC on June 18th?
13:49:16 <JereK> ... No objections recorded
13:49:35 <JereK> RESOLUTION: Agreed to public LCWD of A&E as soon as it is ready.
13:50:24 <JereK> Time for a break, testing with Kai Hendry next.
13:51:00 <anne> Marcos, cheers, getting confused by all the abbreviations
13:53:04 <JereK> For the record, "A&E" is Widgets 1.0: APIs and Events
14:17:50 <ArtB> Scribe+ Josh
14:18:14 <ArtB> Topic: Window Modes / Query spec
14:18:26 <ArtB> ScribeNick: timeless_mbp
14:26:49 <DKA> DKA has joined #wam
14:29:44 <mhanclik> mhanclik has joined #wam
14:29:53 <ArtB> Window Modes: http://dev.w3.org/cvsweb/2006/waf/widgets-wm/
14:30:21 <timeless_mbp> http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-wm/Overview.src.html?rev=1.1&content-type=text/html;%20charset=iso-8859-1
14:31:08 <timeless_mbp> AB: Marcin has noted that we should do some work on this
14:31:09 <hendry> in http://hasather.net/widgets/widgets.rnc : application, floating, fullscreen, mini, all
14:31:16 <timeless_mbp> ... Brian, you agreed to provide some input
14:31:28 <timeless_mbp> ... in the absence of any real inputs, then we'll just open the floor for comments
14:31:39 <timeless_mbp> ... when we're done with that, we'll talk about what's the next step
14:32:18 <timeless_mbp> JS: useless comment to marcos :)
14:32:43 <timeless_mbp> AB: this was cobbled together in Paris based on a rough consensus
14:33:03 <timeless_mbp> Kai: what are the view modes defined by this specification?
14:33:30 <timeless_mbp> Marcin: We had a discussion yesterday, what is discussed here is window mode, like full screen
14:33:57 <timeless_mbp> MC: In the media query specification, they define different features for media types
14:34:30 <timeless_mbp> RB: If we wanted to balance this, we could call these the "docked media feature", ...
14:35:15 <timeless_mbp> AB: let me give a little bit of background; during the february meeting, we realized that we wanted the packaging spec to proceed and not be blocked on window modes
14:35:37 <timeless_mbp> ... we agreed that P&C would have absolute minimal definitions and the canonical list of values
14:35:49 <timeless_mbp> ... and this spec would contain the fleshed out definitions
14:35:54 <timeless_mbp> ... I believe this document is version 1.0
14:36:17 <timeless_mbp> ... what is here is what was entered in february and has no attention since then
14:36:36 <timeless_mbp> Kai: Was what I wrote on irc the list?
14:36:38 <timeless_mbp> MC: yes
14:37:32 <timeless_mbp> BS: I'm trying to understand "media feature", I'm familiar w/ SIP, but you're referring to CSS "media feature"
14:37:45 <timeless_mbp> <http://www.w3.org/TR/css3-mediaqueries/>
14:37:53 <timeless_mbp> <www.w3.org/TR/css3-reader>
14:38:00 <timeless_mbp> <https://developer.mozilla.org/En/CSS/Media_queries ->
14:38:55 <timeless_mbp> Kai: how do media modes relate to things like application/floating/fullscreen?
14:39:16 <timeless_mbp> MC: these don't line up because the spec is out of date
14:39:27 <timeless_mbp> ... we intend to update it to align with P&C
14:39:44 <timeless_mbp> BS: is this intended to address audible media modes?
14:39:51 <timeless_mbp> MC: yes ... 
14:40:04 <timeless_mbp> ... e.g. @media aural and (widget-mode: docked) { .... }
14:40:41 <timeless_mbp> AB: the things after @media <here> are defined by CSS3
14:41:33 <timeless_mbp> AB: what we're saying is that the author can further qualify @media modes with widget-modes to affect how things are rendered
14:41:41 <timeless_mbp> MC: I don't think you can change the @media
14:42:01 <timeless_mbp> BS: what about changing from minimized to maximized
14:42:08 <timeless_mbp> RB: those are widget-mode, not @media
14:42:21 <timeless_mbp> BS: oh, i'm confusing those two things, because the two specs interact
14:42:48 <timeless_mbp> RB: the examples shouldn't be there, there should be more text, there should be examples with details in the rules
14:43:09 <timeless_mbp> BS: So I can test things with this?
14:43:20 <timeless_mbp> MC: You could use A&E to do that instead
14:43:40 <timeless_mbp> MC: Except media type changed event would tell you about some things here
14:45:21 <timeless_mbp> Benoit: we put in ResolutionEvent in Paris because it needed to be somewhere
14:45:34 <timeless_mbp> ... and if someone complains *and* provides it where it belongs, we'll gladly remove it
14:46:50 <abraun> abraun has joined #wam
14:47:38 <timeless_mbp> JS: There are two modes here
14:47:58 <timeless_mbp> ... The media types will be unlikely to change for the life span of an instance on a device
14:48:12 <timeless_mbp> ... And widget modes which the widget will be able to ask the user agent to change
14:48:43 <timeless_mbp> ... What this spec allows is for the widget to use CSS to control how the widget is presented according to the intersection of these two criteria
14:49:52 <timeless_mbp> BS: The combination of the media type and the widget mode allow the widget to style its presentation in that combination. And that's the purpose of this spec?
14:49:55 <timeless_mbp> Benoit: exactly
14:50:13 <timeless_mbp> BS: And the other thing is some event stuff, which should be elsewhere?
14:50:17 <timeless_mbp> Benoit: yes
14:50:32 <timeless_mbp> Benoit: The general issue is that in the P&C spec, there was a need to define modes
14:50:51 <timeless_mbp> ... This spec is to enable the P&C spec not to have that stuff, because it was too much information
14:50:59 <timeless_mbp> BS: do we expect of have more features here?
14:51:16 <timeless_mbp> ... the feature to me is an example of a widget mode. Widget, Docked, Full Screen
14:51:31 <timeless_mbp> ... Application
14:51:39 <timeless_mbp> BS: In Widget mode, you get a box?
14:51:47 <timeless_mbp> Benoit: Not even a box, just a space
14:51:50 <timeless_mbp> BS: Will there be more?
14:52:00 <timeless_mbp> Benoit: I believe that set was defined
14:52:06 <timeless_mbp> AB: Let me find the reference
14:52:10 <timeless_mbp> Benoit: this was discussed
14:52:38 <timeless_mbp> BS: what about icons?
14:52:39 <timeless_mbp> Benoit: there were reasons icons were taken out
14:52:46 <timeless_mbp> BS: this set of modes is presumed to be complete?
14:52:49 <timeless_mbp> AB: Yes.
14:53:04 <timeless_mbp> MO: Icons. Was that related to notifications?
14:53:26 <timeless_mbp> AB: I wouldn't say it was never covered. We talked about icons being one of the states
14:54:11 <timeless_mbp> JS: The reason we don't have icons in the list is because icons coexist with another state
14:54:28 <timeless_mbp> AB: P&C has 5 values, what's the definition of mini?
14:54:38 <timeless_mbp> RB: it's not very well specified
14:54:50 <timeless_mbp> MC: It's a mode that's smaller than full screen
14:55:01 <timeless_mbp> Benoit: originally this comes from Vista where you have docked and undocked
14:55:09 <timeless_mbp> MC: You have full screen...
14:55:18 <timeless_mbp> ... Application, which is slightly smaller with some chrome
14:55:24 <timeless_mbp> ... Floating, which is application with no chrome
14:55:39 <timeless_mbp> ... Mini, which is UA specific
14:56:01 <timeless_mbp> RB: Art, maybe you can iTunes to show Mini player
14:56:35 <timeless_mbp> (Art shows iTunes in Mini mode, and RT pokes fun at RB)
14:56:51 <timeless_mbp> MC: it's up to the implementation to say which mode it's putting things in
14:57:01 <timeless_mbp> RB: it would be nice to have semantics to the keywords
14:57:31 <timeless_mbp> BS: What about all?
14:57:45 <timeless_mbp> RB: all is useful for having a rule that applies to all modes
14:57:52 <timeless_mbp> BS: Can I query for mode all?
14:57:58 <timeless_mbp> Benoit: No
14:58:08 <timeless_mbp> RB: But if you queried to see if it matched all, it'd say yes
14:58:09 <abraun> abraun has joined #wam
14:58:49 <timeless_mbp> Marcin: We have widgetMode, viewPort and widget-mode
14:59:06 <timeless_mbp> AB: We recognize that this draft is out of date/sync
14:59:13 <timeless_mbp> Marcin: the question is do we need this document
15:00:14 <MagnusO> MagnusO has joined #wam
15:00:26 <timeless_mbp> ... currently what's needed in terms of modes is already listed outside this specification
15:00:32 <timeless_mbp> ... A&E offers an api to get/set modes
15:00:45 <hendry> Marcos: floating in terms of X means a window that isn't tiled (~docked) or fullscreen. It has no relation to chrome. /me worried there might be confusion.
15:00:56 <timeless_mbp> ... for me it seems like media query is an informational document
15:01:37 <timeless_mbp> Marcin: but what about all?
15:01:45 <timeless_mbp> RB: I don't think all will be exposed
15:01:52 <timeless_mbp> Benoit: All is for CSS
15:02:23 <MagnusO> Howis ALL related to Fullscreen?
15:02:28 <timeless_mbp> Marcin: Could we add a note that 'all' will never be returned by A&E viewMode?
15:02:58 <Zakim> Zakim has joined #wam
15:03:31 <timeless_mbp> (MC points to the P&C spec with some section highlighted)
15:03:47 <timeless_mbp> (including "all")
15:05:01 <timeless_mbp> Marcin: The issue is that we're using the same token list for 3 places
15:05:11 <timeless_mbp> ... but in one place it doesn't fit (A&E)
15:05:38 <MagnusO> So ALL is really same as able to appear in any form, full, mini etc.
15:05:42 <timeless_mbp> MC: What I am getting is that i need to clarify where/when all is ok
15:05:58 <timeless_mbp> Benoit: All should be listed in its own sentence
15:06:09 <timeless_mbp> RB: yes, outside the original list, with an explanation.
15:06:16 <timeless_mbp> AB: The default is floating
15:06:43 <timeless_mbp> MC: In addition, the all keyword can be used to denote that all the valid view modes are supported by the widget
15:06:45 <timeless_mbp> JS: +1
15:07:03 <mhanclik> mhanclik has joined #wam
15:08:05 <timeless_mbp> (offtopic chatter)
15:08:29 <timeless_mbp> Marcin: P&C talks about a widget views spec
15:08:39 <timeless_mbp> ... and widgets views spec is really green -- not yet defined
15:08:54 <timeless_mbp> ... and we can take P&C to a certain state
15:09:02 <timeless_mbp> AB: It isn't undefined, it's underdefined
15:09:30 <timeless_mbp> ... Again, we ask that if people have inputs for window modes/views, we ask for inputs
15:09:48 <timeless_mbp> Marcin: and we're asking for input as quickly as possible
15:10:03 <timeless_mbp> MC: We intend to publish a first working draft (FWD) the first week of July
15:13:11 <timeless_mbp> BS: The height and width attribute in P&C have a reference to the widget views spec
15:13:27 <timeless_mbp> AB: We need to make sure Widgets VIews talks about which modes would support this
15:14:30 <timeless_mbp> AB: Some of us feel that User Agents should have flexibility wrt what modes might support this stuff
15:14:35 <MikeSmith> MikeSmith has joined #wam
15:16:20 <timeless_mbp> BS: This should be easy, right?
15:18:25 <timeless_mbp> BS: Which attributes are dependent on view modes, and which are independent. and could we have a table?
15:18:32 <timeless_mbp> AB: That sounds great for someone to write
15:19:00 <timeless_mbp> ACTION: Bryan to make a table (if it's easy)
15:19:01 <trackbot> Created ACTION-357 - Make a table (if it's easy) [on Bryan Sullivan - due 2009-06-17].
15:20:25 <timeless_mbp> Topic: Testing
15:22:00 <timeless_mbp> Kai: Widget testing. My name is Kai Hendry. I work for Aplix Corporation.
15:22:18 <timeless_mbp> ... I spend one day a week on the Mobile Web Testing group, which a w3 wg
15:22:43 <timeless_mbp> ... Have you heard of the Mobile Web Compatibility Test for Mobile Browsers?
15:22:48 <timeless_mbp> (many hands raise)
15:22:57 <timeless_mbp> ... Widget Tests!. So I started months ago
15:23:14 <timeless_mbp> .... Marcos told me that some things were stable, so I started working.
15:23:27 <DKA> Web Compatibility Test for Mobile Browsers: http://www.w3.org/2008/06/mobile-test/doc.html
15:23:31 <timeless_mbp> ... I wrote a blog about these tests
15:23:38 <DKA> I am a big fan.
15:24:26 <timeless_mbp> ... I wrote a bunch of zip files for testing
15:24:37 <hendry> http://wtf.webvm.net/
15:24:59 <timeless_mbp> ... That's the next thing I've been doing, with a guy named Robert from Opera
15:25:12 <timeless_mbp> http://dabase.com/
15:25:20 <timeless_mbp> http://dabase.com/blog/Widget_Test_Framework/
15:25:42 <timeless_mbp> Kai: The idea with WTF is you point your Widget Runtime....
15:25:48 <timeless_mbp> ... there is a test harness
15:26:13 <timeless_mbp> ... did you want to write some tests? i could show you how this works :)
15:26:53 <timeless_mbp> ... A lot of the tests are automated in that you have a config.xml and the widget would load, and you would query it with the widget API to see if the widget would load
15:27:08 <timeless_mbp> ... You would load the widget, test a property and see if it's correct and post a result
15:27:56 <timeless_mbp> ... To get more done, it would be good if the spec was stable
15:28:10 <timeless_mbp> ... If you want to help out, you could provide some tests
15:28:23 <timeless_mbp> ... Or if you wanted me to add something, you could email me
15:28:38 <timeless_mbp> Benoit: do you have any target objectives?
15:29:07 <timeless_mbp> Kai: not really. I tried to pin it to when the spec was going to be stable, but that stopped being realistic
15:29:16 <timeless_mbp> ... It's been a learning experience
15:29:30 <timeless_mbp> ... At first I wrote things by hand
15:30:15 <DKA> hand
15:30:21 <DKA> q-
15:30:27 <timeless_mbp> Kai: I learned from Opera to use JS to generate tests
15:30:35 <timeless_mbp> MC: I think we will contribute stuff
15:31:09 <timeless_mbp> Kai: The [Opera] Spartan stuff is really cool, because it can do stuff with (green/red) colors on the screen
15:31:14 <timeless_mbp> AB: I have some questions
15:31:26 <timeless_mbp> ... Kai, at one point in time you were maintaining this CVS repository
15:31:59 <timeless_mbp> Kai: I use git and dump to Dom, and he pushes to CVS
15:32:12 <timeless_mbp> ACTION: Art to coordinate with Kai and Dom
15:32:12 <trackbot> Created ACTION-358 - Coordinate with Kai and Dom [on Arthur Barstow - due 2009-06-17].
15:32:36 <timeless_mbp> AB: The LC period for P&C ends June 19
15:32:55 <timeless_mbp> ... Assuming we don't get any major issues in the next 9 or 10 days, and we should enter Candidate by the end of the month
15:33:28 <timeless_mbp> ... In order to begin the Candidate phase is to define how we get out of Candidate phase by declaring a call for implementations
15:33:43 <timeless_mbp> ... which involves us defining a complete test suite
15:34:12 <timeless_mbp> MC: how do we judge if the changes we've made to the spec are substantive enough to prevent us from doing CR v. LC?
15:34:22 <timeless_mbp> MS: The WG decides
15:34:37 <anne> (Actually, per the Process document you'd have to go back to WD even, not another LC, as I understand things.)
15:35:05 <anne> (And it's a MUST requirement too. Substantive change is defined here: http://www.w3.org/2005/10/Process-20051014/tr.html#substantive-change )
15:35:27 <timeless_mbp> AB: What he says is true
15:35:37 <timeless_mbp> ... that assumes we've had a substantial comment
15:35:59 <anne> (Actually, Marcos already made a substantive change...)
15:36:08 <timeless_mbp> Benoit: We've already raised this question
15:37:16 <timeless_mbp> MC: He's made the assertion that we've made substantive changes
15:37:37 <timeless_mbp> DA: I'm saying that what constitutes substantive changes is up to the Chair
15:37:56 <timeless_mbp> RB: A good definition of a substantive changes is something which would cause an existing implementation to cease to be conformant
15:38:53 <tlr> the important point when going to CR is "does the change invalidate previous review"
15:39:20 <anne> it's all defined in the above link
15:39:21 <timeless_mbp> MC: There are a bunch of changes, including an l10n change yesterday
15:39:34 <anne> new rules for case sensitivity of folders certainly would affect any implementation
15:40:42 <timeless_mbp> AB: We can as long as we the working group by consensus determine that the changes are substantive
15:40:56 <timeless_mbp> RB: What we have to do is list the changes in the transition request
15:41:01 <timeless_mbp> ... and then it's up to the director to decide
15:41:21 <timeless_mbp> MS: Ultimately, that's what it comes down to, and that's where it would be arbitrated
15:44:51 <timeless_mbp> Action-5?
15:44:51 <trackbot> ACTION-5 -- Olli Pettay to produce test template for D3E -- due 2008-06-25 -- CLOSED
15:44:51 <trackbot> http://www.w3.org/2008/webapps/track/actions/5
15:45:11 <timeless_mbp> Action-358?
15:45:11 <trackbot> ACTION-358 -- Arthur Barstow to coordinate with Kai and Dom -- due 2009-06-17 -- OPEN
15:45:11 <trackbot> http://www.w3.org/2008/webapps/track/actions/358
15:45:39 <timeless_mbp> AB: Kai, is it safe to assume that Dom is in the loop that he's checked on the License status?
15:45:56 <timeless_mbp> Kai: The copyright is probably my employer. But we're flexible
15:46:35 <Marcos>  /me hhmmmm... "Show evidence of wide review.".... wonder how that will apply to Widgets Dig Sig. 
15:46:52 <timeless_mbp> ACTION: Art to work with Mike and Dom and Kai on the license+copyright on the Test Suite
15:46:52 <trackbot> Created ACTION-359 - Work with Mike and Dom and Kai on the license+copyright on the Test Suite [on Arthur Barstow - due 2009-06-17].
15:47:18 <timeless_mbp> AB: Kai, the spec that's most ready for testing is the Digital Sig spec
15:47:43 <timeless_mbp> ACTION: Art to ping TLR and FH regarding reuse of XMLDigSig1.0 Test Suite
15:47:44 <trackbot> Created ACTION-360 - Ping TLR and FH regarding reuse of XMLDigSig1.0 Test Suite [on Arthur Barstow - due 2009-06-17].
15:48:01 <timeless_mbp> Kai: Do they have a test suite for 1.0?
15:48:26 <tlr> the tests for 1.1 were very, very specific
15:48:33 <timeless_mbp> RB: They have one, there's been a requirement to reach PR to have a test suite
15:48:37 <tlr> strike 1.1, make that 2nd ed
15:49:08 <timeless_mbp> JS: tlr, is there a link?
15:49:43 <timeless_mbp> AB: The assumption is that we'd be able to leverage that test suite
15:50:00 <timeless_mbp> Kai: their suite should be simple, right?
15:50:20 <timeless_mbp> ... and detached, applicable to SHA256 and x509....
15:50:50 <timeless_mbp> ACTION: Art to find or create examples of widgets digital signature documents - helloWorld
15:50:50 <trackbot> Created ACTION-361 - Find or create examples of widgets digital signature documents - helloWorld [on Arthur Barstow - due 2009-06-17].
15:50:59 <timeless_mbp> AB: Anything else on testing?
15:51:30 <timeless_mbp> AB: I think we should pause and look at anne's submissions
15:52:02 <darobin> <anne> I don't like the link colour, it should be pink
15:53:00 <timeless_mbp> AB: Kai, would you walk us through an example?
15:54:46 <anne> pink is dafunkz
15:55:25 <timeless_mbp> (Kai puts up his test framework)
15:55:43 <timeless_mbp> <http://wtf.webvm.net/>
16:00:09 <timeless_mbp> Kai: Questions?
16:00:23 <timeless_mbp> MC: How do you record which assertion from the spec you've tested
16:00:36 <timeless_mbp> Kai: I've tried to name things sensibly
16:00:51 <timeless_mbp> ... After the chapters of your specification
16:28:36 <darobin> one example: http://www.w3.org/Graphics/SVG/1.2/Tiny/ImpReport.html
16:29:30 <MikeSmith> MikeSmith has joined #wam
16:32:07 <timeless_mbp> Kai: The Bondi Widget runtime is likely to be one of the two interoperable implentations
16:32:10 <abraun> abraun has joined #wam
16:36:02 <timeless_mbp> RT: Kai's statement was overly enthusiastic
16:36:11 <timeless_mbp> DA: it's a possible candidate
16:38:34 <timeless_mbp> AB: Meeting Adjourned
16:38:43 <timeless_mbp> RRSAgent: Make minutes
16:38:43 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/10-wam-minutes.html timeless_mbp
16:43:44 <hendry> http://www.rcguk.biz/RC/RCMenuQW.html
16:44:12 <MikeSmith> Zakim, leave
16:44:12 <Zakim> Zakim has left #wam
16:44:14 <ArtB> RRSAgent, bye
16:44:14 <RRSAgent> I see 7 open action items saved in http://www.w3.org/2009/06/10-wam-actions.rdf :
16:44:14 <RRSAgent> ACTION: Marcos to define installation and instantiation  [1]
16:44:14 <RRSAgent>   recorded in http://www.w3.org/2009/06/10-wam-irc#T09-56-26
16:44:14 <RRSAgent> ACTION: Mhanclik to investigate definitions of installation instantiation in BONDI work  [2]
16:44:14 <RRSAgent>   recorded in http://www.w3.org/2009/06/10-wam-irc#T09-58-49
16:44:14 <RRSAgent> ACTION: Bryan to make a table (if it's easy) [3]
16:44:14 <RRSAgent>   recorded in http://www.w3.org/2009/06/10-wam-irc#T15-19-00
16:44:14 <RRSAgent> ACTION: Art to coordinate with Kai and Dom [4]
16:44:14 <RRSAgent>   recorded in http://www.w3.org/2009/06/10-wam-irc#T15-32-12
16:44:14 <RRSAgent> ACTION: Art to work with Mike and Dom and Kai on the license+copyright on the Test Suite [5]
16:44:14 <RRSAgent>   recorded in http://www.w3.org/2009/06/10-wam-irc#T15-46-52
16:44:14 <RRSAgent> ACTION: Art to ping TLR and FH regarding reuse of XMLDigSig1.0 Test Suite [6]
16:44:14 <RRSAgent>   recorded in http://www.w3.org/2009/06/10-wam-irc#T15-47-43
16:44:14 <RRSAgent> ACTION: Art to find or create examples of widgets digital signature documents - helloWorld [7]
16:44:14 <RRSAgent>   recorded in http://www.w3.org/2009/06/10-wam-irc#T15-50-50