- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Thu, 1 Apr 2010 11:14:50 -0400
- To: public-webapps <public-webapps@w3.org>
The draft minutes from the April 1 Widgets voice conference are available at the following and copied below: http://www.w3.org/2010/04/01-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before April 8 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conference 01 Apr 2010 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0979.html See also: [3]IRC log [3] http://www.w3.org/2010/04/01-wam-irc Attendees Present Art, Thomas, Steven, Robin, Marcos, bryan_sullivan, Josh, Kenneth Regrets Frederick, Marcin Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]Widget DigSig spec: C14N bug 4. [8]P&C spec: <span> and dir 5. [9]TWI spec: Issue #116 6. [10]TWI spec: interop status 7. [11]WARP spec: test suite status 8. [12]URI Scheme spec: Action-510 9. [13]View Modes Media Feature spec: comments from CSS WG 10. [14]View Modes Interfaces spec: 11. [15]AOB * [16]Summary of Action Items _________________________________________________________ <scribe> Scribe: Art <scribe> ScribeNick: ArtB <darobin> ArtB, thanks :) we have quite a few more in the pipeline.... Review and tweak agenda AB: yesterday I posted the agenda ( [17]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/09 79.html ). Any change requests? ... re Widgets Dig Sig, Frederick sent regrets for today but Thomas can join us so we'll make that the first spec. [17] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0979.html Announcements AB: any short announcements? TLR: we are looking into a workshop re privacy and APIs ... specifically, device APIs ... e.g. Geolocation ... TAG has done some related discussing ... CfP could be available in a week or two ... If anyone is interested in helping, ping me offline MC: sounds interesting; I'd like to participate AB: this sounds good; expect Nokia to participate Widget DigSig spec: C14N bug AB: earlier this week, Frederick announced a bug in the Widget DigSig spec related to C14N ( [18]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/09 53.html ). Yesterday he submitted a modified proposed resolution ( [19]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/09 80.html ). ... the main issue is the spec isn't clear which C14N algorithm to use i.e. 1.0 or 1.1 and the proposal is to make it explicit: use 1.1. ... the modified proposal includes 3 normative changes and a couple of non-normative changes. ... for today, mainly want to see if the issue(s) and proposed resolution are clear. [18] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0953.html [19] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0980.html TLR: there may be a bug in the bug ... in the proposed resol re section 7.2 ... some of that text is not correct ... I will follow-up today AB: thank you BS: does this mean that tools that sign will need to change? TR: the change should be fairly minor ... the change to the markup is just explicitly adding the algorithm to use ... If a change is needed, that means you are using 1.0 for the object and 1.1 for everything else ... Changes should be minor, depends on what the impl does BS: so if sign a widget with current tool and then test with updated tool? TR: the old signatures are not likely to be conformant with the spec as changed ... if some type of generic tool was used, it may work BS: having those details would be helpful ... especially for those that have already deployed based on the current spec ... Will need to resign? TR: if a widget is signed according to old spec and uses 1.0 ... then want to know if 1.1 verifier will throw an error or not BS: need to clear answer to these deployement questions TR: read Frederick's email ... there is should level support for 1.0 BS: OK; will read it TR: I will follow-up in email today AB: let's try to respond to FH and TLR's emails by April 8 ... want to know by then if this is going to cause major problems or not P&C spec: <span> and dir AB: the last thread on Marcos' new <span> and dir model is ( [20]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/09 36.html ). Marcos, what's the status? [20] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0936.html MC: I think we might be done <scribe> ... pending one note UNKNOWN_SPEAKER: i.e. the security precautions ... unicode and URIs AB: have you received any responses to your revised proposal? MC: they said they will reivew at next voice conf AB: so we'll need to wait for them to respond ... re next steps with this spec, I'm not sure we can go straight to PR MC: we can argue we haven't really changed functionality RB: I think it is a small enough change we can go to PR MC: I created some tests ... but we need some way to run the tests AB: what % of the dir and span tests are completed? MC: I just have a skeleton; haven't created actual widgets RB: re how to run the tests ... this is no diff from other aspects of the config file ... i.e. they don't show in the UA's UI ... just use dumps or something like that AB: not sure you need to create the same quality of tests we have for our Mandatory tests MC: yes, just need to show the parsing is done correctly AB: Steven, do you think Team will support going to PR? SP: yes, as long as you've got the tests, that should be good enough MC: it will be very diff for us to show a UA that displays the info ... we'll have to take it on an implementor's word that they've "done it" ... our test reports are based on a core parsing engine that doesn't have any UI SP: depends on the exit criteria ... CR should prove the spec is implementable ... need to show they are implemented somewhere and interoperable MC: thanks for the clarification AB: yes, that was helpful ... the PoA is: get closure with I18N WG re the latest changes Marcos proposed and then to proceed to PR ... any disagreements? ... or any concerns? [ No ] <darobin> +1 TWI spec: Issue #116 AB: Issue-116 is "Need to flesh out the security considerations for the openURL method in the Widget Interface spec" ( [21]http://www.w3.org/2008/webapps/track/issues/116 ). Marcos, what's the status on the proposed text? [21] http://www.w3.org/2008/webapps/track/issues/116 MC: we are still sorting it out ... I don't have a new proposal ... but hope to have something soon AB: is there something the rest of us can provide to help? MC: I don't think it will change any normative text ... we are blocked on implementations ... don't think we need to worry about it TWI spec: interop status AB: the TWI Implementation Report ( [22]http://dev.w3.org/2006/waf/widgets-api/imp-report/ ) indicates Opera passes 100% of the tests. We need another implementation to pass 100% of the tests to exit Candidate. Can anyone provide some additional implementation data? [22] http://dev.w3.org/2006/waf/widgets-api/imp-report/ RB: I do plan to make an update within two weeks AB: for widgeon? RB: for a new approach for widgeon AB: does anyone else have impl data they can share? WARP spec: test suite status AB: what is the status of the WARP test suite ( [23]http://dev.w3.org/cvsweb/2006/waf/widgets-access/test-suite/ )? [23] http://dev.w3.org/cvsweb/2006/waf/widgets-access/test-suite/ RB: nothing recent from me MC: nothing recent from me either ... the spec has been marked-up for testing ... just need the tests ... I'd like to move this to CR as quickly as possible ... and I don't think we need a test suite before publishing the CR RB: I'm fine with that as well AB: any other comments about going to CR now? [ No ] <scribe> ACTION: barstow add proposal to move WARP spec to CR to April 8 agenda [recorded in [24]http://www.w3.org/2010/04/01-wam-minutes.html#action01] <trackbot> Created ACTION-513 - Add proposal to move WARP spec to CR to April 8 agenda [on Arthur Barstow - due 2010-04-08]. URI Scheme spec: Action-510 AB: before I can ping IETF on the status of our scheme registration, Robin needs to respond to Julian re ( [25]http://www.w3.org/2008/webapps/track/actions/510 ). Robin, what's the status of this action? [25] http://www.w3.org/2008/webapps/track/actions/510 RB: I still have some edits to make ... then I will respond ... they have a 4-week review period ... think that ends next week ... I intend to reply to original posters ... and then to uri-review to determine the status ... anyone know about implementation? MC: not sure about our status ... could have been based on an old spec RB: widgeon implements it AB: we had some discussion about the authority View Modes Media Feature spec: comments from CSS WG AB: during our last meeting we had a short discussion re comments from CSS WG re the VMMF spec ( [26]http://www.w3.org/2010/03/18-wam-minutes.html#item06 ) but without Robin, we didn't dive too deep. ... Comments from CSSWG: [27]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/08 04.html ... Comments from Daniel Glazman: [28]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/08 00.html ... Comments from Brad Kemper: [29]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/08 03.html ... Height and width attribute (raised by Marcos): [30]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/08 47.html ... I'd first like to talk about the scope question e.g. keep its scope limited or expand it. Daniel said "why is this restricted to widgets" [26] http://www.w3.org/2010/03/18-wam-minutes.html#item06 [27] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0804.html [28] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0800.html [29] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0803.html [30] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0847.html RB: I agree with DG that it shouldn't be MC: I agree to but what does that mean work wise RB: I think it just means removing any refs to "widgets" <kenneth> me too, btw I have additional comments: [31]http://www.mail-archive.com/public-webapps@w3.org/msg08111.html [31] http://www.mail-archive.com/public-webapps@w3.org/ msg08111.html RB: it could affect the test suite <Marcos> Kenneth, will you join the call? <kenneth> Marcos, can I? <Marcos> certainly is <darobin> kenneth: certainly RB: I can respond to all of the comments AB: there are a couple I'd like to discuss today <kenneth> ok could anyone give me info on how to call? Then I will find a room with wifi MC: re width and height RB: not sure it needs to be in MF spec MC: yes, I kinda' see what you mean RB: in P&C we say they are indications <kenneth> ok I will try! MC: P&C says given width and height, it says what UA does is dependent on the view mode <Marcos> "Authoring Guidelines: It is optional for authors to use the width attribute with a widget element. This value is only applicable to particular view modes, meaning that for certain view modes this value is ignored. The view modes that honor the value of the height attribute are defined in the [Widgets-Views] specification. " MC: but that text is non-normative AB: ah, I see RB: we could just drop that last sentence AB: would that be OK Marcos? MC: I think that would be OK ... don't think it will cause interop probs AB: feels like being silent here is the right approach MC: OK, I will remove those two sentences (once for width and once for height) AB: ok, good ... the need for the "all" value RB: I think it makes sense to have a catch-all ... an API could return all ... and it tends to be consistent with some of the other MQs ... I'm not married to it ... Kinda' like the inherit value KC: but isn't it equiv to not having anything RB: I just copied it from MQs stuff KC: if have any new view modes in the feature, it would cause probs RB: if can match on all, then know the UA supports view-mode KC: could just ask for view-mode then MC: on the config side, leaving view mode out equates to all ... which equates to view mode <Marcos> <widget viewmodes=""> AB: so there would be some consistency for not having it? ... would anyone object to it being removed? RB: I would not KC: could clarify it is always true if it is a widget RB: but we don't want to tie it to widget AB: proposed RESOLUTION: the "all" value will be removed from the VM-MF spec <darobin> +1 AB: any objection? RESOLUTION: the "all" value will be removed from the VM-MF spec AB: the "hidden" value DG proposed RB: I can see some value ... e.g. stopping a CSS animation AB: without more compelling use case and resources to drive it, not sure about it KC: may want to stop CSS animations on mobile devices e.g. to save battery JS: is that a UA problem or author issue? KC: may want to give author control ... some of the names are confusing RB: I'm ok with windowed instead of application MC: I'm OK with that but we've already implemented "app" RB: I don't want to bikeshed on names AB: agree MC: yes, but we do have implementations ... we don't want to invalidate them RB: they should be use -X KC: in webkit, using -webkit RB: MC, can you get us some data <Marcos> [32]http://widget.vodafone.com/dev/ [32] http://widget.vodafone.com/dev/ RB: need to be careful here AB: without substantial reasons to change, not sure we should change them KC: need to make them more general RB: the entire spec is more general KC: should be relatively easy to support different names RB: I'd like to get implementors debate this on the mail list AB: any other comments on VM-MF for today? View Modes Interfaces spec: AB: during the discussion about the pre-LC version of the VMMF spec, questions were asked about the relationship between VM-I spec and CSSOM specs ( [33]http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html ) and ( [34]http://dev.w3.org/csswg/cssom-view/ ) via the thread ( [35]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/09 33.html ) [33] http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html [34] http://dev.w3.org/csswg/cssom-view/ [35] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0933.html KC: need a way to change the View Mode from JavaScript ... everything else is already in CSSOM AB: are you saying VM-I spec isn't really needed KC: just need the view mode change stuff moved into CSSOM MC: it would be ideal if CSSOM Editor and Kennett could work today and make sure our use cases get into the CSSOM spec KC: not sure how that would work in practice MC: we're happy to help <scribe> ACTION: barstow work with Kenneth on a plan to address VM-I use cases and reqs via the CSSOM spec [recorded in [36]http://www.w3.org/2010/04/01-wam-minutes.html#action02] <trackbot> Created ACTION-514 - Work with Kenneth on a plan to address VM-I use cases and reqs via the CSSOM spec [on Arthur Barstow - due 2010-04-08]. AOB AB: does anyone have any other discussion points for today? ... next meeting will April 8 MC: will charter be renewed by then? AB: no <Marcos> "When the attribute is missing, or is left empty, it implies that the author allows the user agent to select and appropriate viewmode for the widget." <timeless_mbp> … it indicates the author has not requested a specific viewmode <timeless_mbp> ? AB: meeting adjourned Summary of Action Items [NEW] ACTION: barstow add proposal to move WARP spec to CR to April 8 agenda [recorded in [37]http://www.w3.org/2010/04/01-wam-minutes.html#action01] [NEW] ACTION: barstow work with Kenneth on a plan to address VM-I use cases and reqs via the CSSOM spec [recorded in [38]http://www.w3.org/2010/04/01-wam-minutes.html#action02] [End of minutes]
Received on Thursday, 1 April 2010 15:27:38 UTC