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]
