Widgets Voice Conference

01 Apr 2010


See also: IRC log


Art, Thomas, Steven, Robin, Marcos, bryan_sullivan, Josh, Kenneth
Frederick, Marcin


<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 ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0979.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.


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 ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0953.html ). Yesterday he submitted a modified proposed resolution ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0980.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.

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 ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0936.html ). Marcos, what's the status?

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" ( http://www.w3.org/2008/webapps/track/issues/116 ). Marcos, what's the status on the proposed text?

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 ( 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?

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 ( 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 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 ( http://www.w3.org/2008/webapps/track/actions/510 ). Robin, what's the status of this action?

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 ( http://www.w3.org/2010/03/18-wam-minutes.html#item06 ) but without Robin, we didn't dive too deep.
... Comments from CSSWG: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0804.html
... Comments from Daniel Glazman: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0800.html
... Comments from Brad Kemper: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0803.html
... Height and width attribute (raised by Marcos): http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0847.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"

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: 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> 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 ( http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html ) and ( http://dev.w3.org/csswg/cssom-view/ ) via the thread ( 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 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].


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 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 http://www.w3.org/2010/04/01-wam-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/04/01 14:21:46 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/DR/RB/
Found Scribe: Art
Found ScribeNick: ArtB
Present: Art Thomas Steven Robin Marcos bryan_sullivan Josh Kenneth
Regrets: Frederick Marcin
Agenda: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0979.html
Got date from IRC log name: 01 Apr 2010
Guessing minutes URL: http://www.w3.org/2010/04/01-wam-minutes.html
People with action items: add barstow proposal

[End of scribe.perl diagnostic output]