[widgets] Draft Minutes for 21 January 2010 voice conference

The draft minutes from the 21 January 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 4 February (the next  
Widgets voice conference); otherwise these minutes will be considered  

There will be no call on 28 January.

-Regards, Art Barstow


       [1] http://www.w3.org/

                                - DRAFT -

                        Widgets Voice Conference

21 Jan 2010


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

    See also: [3]IRC log

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


           Art_Barstow, Marcin_Hanclik, Steve_Jolly, Josh_Soref, Arve,

           Frederick_Hirsch, Marcos_Caceres, Robin_Berjon




      * [4]Topics
          1. [5]Review and tweak agenda
          2. [6]Announcements
          3. [7]WARP spec: LC comments
          4. [8]WARP spec: extending access to local network resources
          5. [9]URI Scheme spec: LC comments
          6. [10]View Modes Media Features spec
          7. [11]AOB
      * [12]Summary of Action Items

    <scribe> ScribeNick: ArtB

    <scribe> Scribe: Art

    Date: 21 January 2010

    <marcin> ups :)

    <timeless_mbp> Zakim: who is on?

Review and tweak agenda

    AB: the agenda was submitted on January 20 (
    17.html ). Any change requests?
    ... without Robin here, we will need to make some modifications

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


    AB: does anyone have any short announcements? The only one I have is
    that we will not have a call on January 27.

WARP spec: LC comments

    AB: the WARP LC (
    [14]http://www.w3.org/TR/2009/WD-widgets-access-20091208/ ) comment
    period ended 13 January (
    ccess-20091208/ ). I believe we only received 2 comments, from
    Marcos and Dom.
    ... Marcos (Dec 21,
    72.html ) and Dom (Dec 10,
    [17]http://www.w3.org/mid/1260460310.3355.2561.camel@localhost ).
    ... we can't proceed to CR until we have done the necessary
    round-tripping with the Commentors

      [14] http://www.w3.org/TR/2009/WD-widgets-access-20091208/
      [15] http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- 
      [16] http://lists.w3.org/Archives/Public/public-webapps/ 
      [17] http://www.w3.org/mid/1260460310.3355.2561.camel@localhost

    <scribe> ACTION: Robin process the LC comments for the WARP LC
    [recorded in

    <trackbot> Created ACTION-478 - Process the LC comments for the WARP
    LC [on Robin Berjon - due 2010-01-28].

    AB: everyone else in the WG is also encouraged to respond to the LC
    ... anything else on WARP LC?

    <Steven-cwi> Apologies for lateness

    <scribe> ACTION: barstow make sure all WG members know about the
    PAG's mail list [recorded in

    <trackbot> Created ACTION-479 - Make sure all WG members know about
    the PAG's mail list [on Arthur Barstow - due 2010-01-28].

WARP spec: extending access to local network resources

    AB: on January 14 StephenJ (SJ) started a thread (
    73.html ) re extending the <access> element to support local network
    ... Arve and Stephen continued that thread today. What's the status
    (I haven't yet caught up on today's e-mails)?

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

    SJ: I sent my proposal
    ... it is a starting point
    ... want to consider the local net
    ... want developers to be able to specify them as accessible
    ... Arve asked some questions
    ... I think it makes sense to create some UCs and I'll do that
    ... if people have other comments, that's good too

    Arve: for our impl at Opera, developers have been not understood
    very well the diff between local and non-local
    ... and have just given permission to everything because of the
    ... so that is something to consider

    SJ: needs to be at least one good UX to accept or reject local
    ... could be a number of networks available, especially in a mobile
    network (wifi, operator net, etc.)
    ... there is lots of more data that may be available

    Arve: I'm not sure how much we need to standardize

    SJ: how much info is needed for these UCs?

    AB: we don't have any template

    Arve: I don't expect a whole lot of details
    ... if you respond to the email, that should be sufficient

    SJ: ok, no problem

    <scribe> ACTION: jolly submit a UC for the local network access
    proposal [recorded in

    <trackbot> Created ACTION-480 - Submit a UC for the local network
    access proposal [on Stephen Jolly - due 2010-01-28].

    AB: is there anything else on this topic for today?

    [ No ]

URI Scheme spec: LC comments

    AB: the LC comment tracker (
    ri-20091008/doc/ ) indicates 7 of the 9 comments are still in the
    "tocheck" status.
    ... my take on Larry Masinter's 18-Dec-2009 reply (
    55.html ) is the two main issues are: 1) he doesn't think we have
    showed "Demonstratable, New, Long-Lived Utility" per RFC4395; and 2)
    "The description of the mapping must be complete", in particular
    authority. Links to the authority thread are included in the draft
    ... without Robin, I'm not sure it makes sense to do a deep dive on
    ... when we get Robin on a call, we will need to discuss these

      [22] http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- 
      [23] http://lists.w3.org/Archives/Public/public-webapps/ 

    MH: think we should first discuss on the mail list

    AB: yes, I agree we should discuss as much as possible on the mail
    ... One thing LM asks for is a Use Case that clearly demonstrates
    "New URI schemes SHOULD have clear utility to the broad Internet
    community, beyond that available with already registered URI
    schemes."  RFC4395 [24]http://tools.ietf.org/html/rfc4395 ]. LM
    asserts the thismessage scheme [ RFC2557
    [25]http://tools.ietf.org/html/rfc2557 ] should be reused or
    modified to meet our requirements.
    ... I fully agree that if some existing scheme meets 100% of our
    reqs, we should re use it
    ... but that doesn't appear to be the case with any of the schemes
    we looked at
    ... we have some a wiki page of schemes we have evaluated (
    [26]http://www.w3.org/2008/webapps/wiki/WidgetURIScheme ). Perhaps
    it would be helpful to analyze this again (RB did last June
    72.html ) but there was no reply by LM.

      [24] http://tools.ietf.org/html/rfc4395
      [25] http://tools.ietf.org/html/rfc2557
      [26] http://www.w3.org/2008/webapps/wiki/WidgetURIScheme
      [27] http://lists.w3.org/Archives/Public/public-webapps/ 

    <Steven-cwi> OK

    AB: I think this is an area where getting some advice and guidance
    from the Team would be helpful
    ... anything else on this topic for today?

    [ No ]

View Modes Media Features spec

    AB: Marcin on Jan 14 sent questions to the list
    ... and there has been no response, correct?

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

    MH: right, no response yet
    ... I have added the comments from VF (as agreed previously)
    ... I have some questions to discuss
    ... re interactivity, I proposed a solution in the ED
    ... mini says content is not interactive
    ... need to know if that affects HTMLInputElement
    ... I assume answers in the ED
    ... but some of my answers may be controversial

    AB: Arve, any follow-up from you on this?

    Arve: re mini, in what way would that affect HTMLInputElement?

    MH: disabled atrribute

    Arve: no, this would not affect that attribute
    ... in mini mode one can still have a distinction between enabled
    and disabled

    MH: does this need to be specified?

    Arve: no; take a look at print media type in CSS and see what
    happens there

    MH: so, you think we should handle this like print media?

    Arve: we probably shouldn't reference HTML at all

    MH: OK, I'll look at that; this could affect the User Experience
    ... then we can discuss over email

    AB: what's the issue with the opacity property?

    MH: not sure how this applies for some of the modes
    ... need to explain this e.g. with body element?

    Arve: no, I don't think we should do that
    ... don't want to tie this to body element

    MH: we have 4 view modes now
    ... transparency depends on UA
    ... widget developer may not be able to detect if viewport is
    transparent or not
    ... don't necessarily want to add more properties and exponentially
    increase the property/view mode table

    <arve> I'm back in, but speaking is difficult

    <arve> landline = flat battery

    MH: want to continue opacity discussion
    ... want author to require opaque viewport but now that can't be
    done - it is up to the UA
    ... In my email I said "I would like to have the widget behave like
    fullscreen or mini, but the transparency could depend on the

    <arve> [We should do that by making opacity attribute separate from
    view mode]

    MH: yes, I'm fine with that
    ... but not sure where that would be specified

    <arve> [config.xml, probably]

    MH: config.xml? CSS?
    ... ok, config.xml

    AB: let's please continue this discussion on the mail list

    <arve> CSS is for adjust certain aspects of presentation in web-type
    documents, while this is about the window type the widget is to be
    rendered in

    AB: anything else on the VM-MF spec for today?

    MH: I'm a bit behind on the VM-I spec but will try to get something
    done by the next call
    ... they are closely related

    AB: ok; understood


    AB: Next call: No call on January 27; next call is Feb 4.
    ... anything else for today?

    JS: regrets for Feb 4

    AB: meeting adjourned

    <Steven-cwi> Jan 28th you meant?

    AB: oops - I meant no call on Jan 28! - next call is Feb 4

Summary of Action Items

    [NEW] ACTION: barstow make sure all WG members know about the PAG's
    mail list [recorded in
    [NEW] ACTION: jolly submit a UC for the local network access
    proposal [recorded in
    [NEW] ACTION: Robin process the LC comments for the WARP LC
    [recorded in

    [End of minutes]

Received on Thursday, 21 January 2010 14:54:32 UTC