W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

[widgets] Draft minutes for 1 April 2010 voice conf

From: Arthur Barstow <art.barstow@nokia.com>
Date: Thu, 1 Apr 2010 11:14:50 -0400
Message-Id: <EB785C41-68AB-47D9-A8A8-60B1DD57DB20@nokia.com>
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:


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] http://www.w3.org/

                                - DRAFT -

                        Widgets Voice Conference

01 Apr 2010


       [2] http://lists.w3.org/Archives/Public/public-webapps/ 

    See also: [3]IRC log

       [3] http://www.w3.org/2010/04/01-wam-irc


           Art, Thomas, Steven, Robin, Marcos, bryan_sullivan, Josh,

           Frederick, Marcin




      * [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

Review and tweak agenda

    AB: yesterday I posted the agenda (
    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/ 


    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 (
    53.html ). Yesterday he submitted a modified proposed resolution (
    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
    ... 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/ 
      [19] http://lists.w3.org/Archives/Public/public-webapps/ 

    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

    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

P&C spec: <span> and dir

    AB: the last thread on Marcos' new <span> and dir model is (
    36.html ). Marcos, what's the status?

      [20] http://lists.w3.org/Archives/Public/public-webapps/ 

    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

    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

    <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:
    ... Comments from Daniel Glazman:
    ... Comments from Brad Kemper:
    ... Height and width attribute (raised by Marcos):
    ... 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

      [26] http://www.w3.org/2010/03/18-wam-minutes.html#item06
      [27] http://lists.w3.org/Archives/Public/public-webapps/ 
      [28] http://lists.w3.org/Archives/Public/public-webapps/ 
      [29] http://lists.w3.org/Archives/Public/public-webapps/ 
      [30] http://lists.w3.org/Archives/Public/public-webapps/ 

    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/ 

    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

    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

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

    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

    <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
    [NEW] ACTION: barstow work with Kenneth on a plan to address VM-I
    use cases and reqs via the CSSOM spec [recorded in

    [End of minutes]
Received on Thursday, 1 April 2010 15:27:38 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:24 UTC