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

[widgets] Draft minutes from 7 May 2009 Voice Conference

From: Arthur Barstow <art.barstow@nokia.com>
Date: Thu, 7 May 2009 10:36:14 -0400
Message-Id: <B5A3E4A7-E1B1-44FC-9764-196B1DF972D4@nokia.com>
To: public-webapps <public-webapps@w3.org>
The draft minutes from the May 7 Widgets voice conference are  
available at the following and copied below:


WG Members - if you have any comments, corrections, etc., please  
sendthem to the public-webapps mail list before 14 May 2009 (the next  
Widgets voice conference); otherwise these minutes will be considered  

-Regards, Art Barstow


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

                                - DRAFT -

                        Widgets Voice Conference

07 May 2009


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

    See also: [3]IRC log

       [3] http://www.w3.org/2009/05/07-wam-irc


           Art, Jere, Thomas, Andy, Mike, Marcos, Robin, Arve

           Josh, David




      * [4]Topics
          1. [5]Review and tweak agenda
          2. [6]Announcements
          3. [7]P&C spec: Proposal to add "required" attribute to
          4. [8]P&C spec: <access> element comments by Thomas
          5. [9]P&C spec: I18N issue: case-sensitivity of locale
          6. [10]P&C spec: status of L10N model agreements
          7. [11]P&C spec: proposal to close Issue #80 (Runtime
             localization model for widgets)
          8. [12]P&C ToDo List aka how to get P&C to LCWD#2
          9. [13]A&E spec: Action 232 - Check the API spec for
             compliance with the Web IDL spec
         10. [14]A&E spec: Action 290 - Review changes to HTML5 that may
             affect API and Events spec and propose a way forward
         11. [15]A&E spec: Red Block issue in section 5.14 "ISSUE: do we
             need to do some kind of URI normalization to check for
         12. [16]Widgets URI spec: Widget instances and widget
         13. [17]Widgets URI spec: Action 338 - "edit access element to
             take into account OMTP feedback and Bryan's"
      * [18]Summary of Action Items

    <scribe> ScribeNick: ArtB

    <scribe> Scribe: Art

    Date: 7 May 2009

    trackbot, associate this channel with #webapps

    <trackbot> Associating this channel with #webapps...

Review and tweak agenda

    AB: I submitted the Draft Agenda on May 6
    499.html). One change is discussing Marcos' P&C ToDo List
    500.html) during the "3.e." agenda item. Any other change requests?

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

    [ None ]


    AB: earlier today I announced a Call for Editor(s) to help with the
    P&C spec but we'll get to that later. Any other announcements?

P&C spec: Proposal to add "required" attribute to <access>

    AB: last week Bryan proposed
    tt-0444/00-part) adding two new requirements to the <access>
    element. Their was agreement the "optional" attribute would be
    deferred until the next version but there was no consensus on the
    "required" attribute. Given this spec is already in LC, my
    inclination is move "required" attribute to the v2 list. Comments?

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

    MC: I agree with defering required attr to v2

    RB: I thought we agreed to add it so I did but I'm also OK with
    dropping it

    AB: what would be the burden of the UA if it was included?

    MC: the UA wouldn't necessarily do anything with it
    ... the URI may not be available

    AB: I propose the "required" attribute be moved to the v2 feature
    ... any objections?

    [ None ]

    RESOLUTION: the "required" attribute will be moved to the v2 feature

    <scribe> ACTION: barstow add the required attribute to the v2
    feature list [recorded in

    <trackbot> Created ACTION-340 - Add the required attribute to the v2
    feature list [on Arthur Barstow - due 2009-05-14].

P&C spec: <access> element comments by Thomas

    AB: last week Thomas submitted several comments regarding the access
    470.html). Earlier today Robin replied to Thomas
    504.html). Let's start with Robin ...

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

    RB: TLR made 5 points
    ... #1 asks for clarification and I've done that in the draft
    ... #2: I kept the name and added a subdomain attr
    ... #3: I'm not exactly sure what TLR is needed
    ... #4 is defined in the spec
    ... #5: I explained the wildcard use

    TR: I will elaborate in another email
    ... there are some details we need to think about
    ... To what extent it is likely someone will want to link to an
    inline image/iframe
    ... Want a widget to do same things a web page can do but nothing
    ... Permiting XHR leads to a larger risk surface
    ... If there is a significant piece of widgetry that uses inline
    content e.g. images, scripts, etc. and do not use XHR then it might
    be worthwhile to separate XHR from the inline requests in the access
    ... Do people have insight if that distinticint exists with authors

    RB: in terms of separateing the two, default is inline use
    ... need to think about security complexities of different contexts

    <tlr> tlr: if you have an access tag, then you're mixing content
    already. That means you need to think about the mix of security
    context anyway. Note that this is most important in the case of

    MC: I don't have any firm ideas on this at this point

    TR: are we trying to close down things a web browser has anyway
    ... or are we saying we want another surface

    MC: we want a separate sec model for widgets
    ... not sure about the implications of using the browser's sec model

    TR: not sure we want to define a diff sec model
    ... what do you want to protect; what is the cost of deviating from
    the browser model
    ... don't want to go that route without compelling reasons

    MC: since we don't have an origin  la web origin, we need to define
    our own model

    TR: could say the signature protects everything
    ... can think about access element as it defines the exceptions to
    the browser sec model

    MC: I think that makes sense

    TR: we need more input, especially from security experts

    MC: this would be better for authors too e.g. developers creating
    iphone apps, etc.

    <darobin> ack

    RB: think we may be mixing conversations
    ... config doc enables a variety of sec models
    ... could say inline is OK and for everything else must go thru
    ... access element defines the metadata for sec model

    TR: I have concerns about that view

    Arve: I have a concerns about the view RB presented

    TR: don't think the access element should defer to a future spec

    MC: I agree

    RB: I think we should separate discusion of access element from
    security policy

    TR: I don't think they are related

    Arve: I agree with TR

    AB: how do we move the P+C spec forward if we need a detailed sec
    model spec?

    TR: could say origin is ignored and can't access network resources
    ... could say a widget is a web page and inherits HTML5 sec model
    ... this means could have inline content
    ... access element could specify exceptions to the same origin
    ... there are pros for both of these models

    Arve: so you want it to be an opt in of the sec model?

    TR: yes

    Arve: not sure how that aligns with operator models and handset
    ... not sure the HTML5 model is acceptable to handset vendors

    TR: we are defining a sec model without reqs for it

    MC: we have a synthetic origin

    TR: need an origin a server can handle

    Arve: not sure why a packaging format needs a detailed sec model

    AB: what's next steps here?

    TR: I will respond to Robin's email
    ... I will also state where I think we are
    ... Want Arve to state his reqs for sec model

    Arve: I can't do that today but it will have to wait a few days

    TR: I will miss next week's call

    AB: please follow-up on the mail list

P&C spec: I18N issue: case-sensitivity of locale subdirectories

    AB: on April 29 Robin made a proposal
    404.html) for addressing case-sensitivity for localize subdirectory
    names. There appears to be consensus that option "b" is preferred.
    Any comments?

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

    <tlr> TR: regrets for 14 and 21 May (argh); happy to do call out of
    normal schedule

    JK: I sent comments on this today
    ... would be good if RB and MC would read those comments
    ... will need to do case comparisions anyway

    MC: OK; I'll followup
    ... I think the proposal was to use ASCII order

    JK: using ASCII may not be a good idea

    AB: so no consensus yet on that issue

P&C spec: status of L10N model agreements

    AB: Marcos, what is the status of you integrating the L10N model
    agreements into the ED?

    MC: I've started to integrate the comments.

    AB: when do you expect to complete that work?

    MC: maybe by mid next week
    ... it effects diff parts of the spec

P&C spec: proposal to close Issue #80 (Runtime localization model for

    AB: given the agreements we reached during the April 30 call
    regarding Marcos' L10N model, I think we can now close Issue #80
    ([26]http://www.w3.org/2008/webapps/track/issues/8) "Runtime
    localization model for widgts". Comments?

      [26] http://www.w3.org/2008/webapps/track/issues/8)

    MC: ok with me

    JK: agree

    AB: any other comments?

    RESOLUTION: Issue #80 is now closed given the agreements from the 30
    April call

P&C ToDo List aka how to get P&C to LCWD#2

    AB: yesterday Marcos submitted a detailed list of open items for the
    P&C spec
    500.html). Thanks for creating this list Marcos! I don't want to
    necessarily do a deep dive for any of these but for each would like
    to understand a) its priority; and b) who will commit to doing the
    ... I see at least four different priorities that could be assigned:
    1) Must be addressed before LCWD #2 is published; 2) can be
    addressed after LCWD #2 is published but before the CR is published;
    3) can be addressed during Candidate; 4) can be moved to the v2
    feature list. Let's see if we can get quick agreement on the
    priorities as well as a firm commitment from someone to complete the
    ... #1 - priority #1
    ... and who?
    ... #1: prio #1 and Marcos
    ... anyone can help?

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

    MC: I'll take it

    JK: I can help; MC, just let me know

    AB: #2:
    ... prio #2?

    RB: not sure; it impacts the processing
    ... I'm willing to take this

    AB: ok, then #2 is prio #1 and RB will take the lead
    ... #3 and #4

    MC: I think RB was going to take these

    RB: I can take #3 and #4

    AB: great; anyone else that can help?

    [ No vols ]

    #5: prio #1 ; Robin is taking the lead already

    scribe: everyone contribute to related discussions

    RB: I'm happy to edit which ever way the group resolves

    AB: #6 is part of the L10N model right?

    MC: yes
    ... perhaps JK can help

    JK: yes, I can help; is there a tentative defn now?

    MC: yes, a 1-line defn
    ... needs to be expanded

    #7: prio #3; can be done during CR phase; Art already agreed to do

    AB: #8: comments?
    ... there has been some offlist discussion to remove these two attrs

    MC: we are unsure now
    ... they are optional
    ... they need to be clearly defined in the Window Modes spec
    ... they make no sense e.g. in full screen mode
    ... but text needs to be tightened up

    AB: so prio #1 for w/h?

    MC: yes

    AB: #9: window modes
    ... is this critical for LCWD #2?

    MC: yes; the change isn't big; I will take this

    AB: #10; this is also related to the L10N model, right?

    MC: given last week's agreement, we don't need xml:base
    ... not clear if we need it or not

    AB: is it in there now?

    MC: yes

    RB: what's in there now is wrong and should be dropped

    JK: agree

    RESOLUTION: Marcos will remove all refs to xml:base from P+C spec

    AB: #11; not sure on the prio of this
    ... not clear this is critical for v1

    MC: it is already specified
    ... and we have a use case
    ... Anne said we don't need it

    AB: so I propose we leave it in
    ... any objections to that?

    RESOLUTION: we will keep the content element attributes related to
    encoding and type

    AB: #12 - param parsing model

    MC: this is high prio and simple cut-and-paste

    AB: can you do that MC or do you need help?

    MC: I can take it

    AB: #13, #14, and #15 are steps 2, 3, and 5

    MC: #13 is a 1-liner
    ... #14 and #15 are L10N

    AB: given that, will you take those?

    MC: yes

    AB: do you need help?

    MC: need someone to review after I'm done
    ... #16 is in the same bucket
    ... it is related to #1

    JK: I am willing to review; just let me know
    ... I can also help write; just let me know

    MC: Jere, can you take finding the base folder and widget locale?

    JK: this aligns with item #6
    ... I'll work on this and get something to MC next week

    MC: I should have something by Monday

    AB: #17 and #18 - these are prio #2 or #3
    ... any disagreements on 17 and 18?

    [ None ]

    AB: if we want the LCWD#2 comment period to end before the June 9-11
    f2f meeting then for a 4-week review period we must publish on May
    11 and for a 3-week review period we must publish on May 18.

    MC: re LC, want to know who we can get to review

    AB: besides the "normal suspects"?

    MC: could we premtively contact people
    ... so people could start pre-allocating time

A&E spec: Action 232 - Check the API spec for compliance with the Web
IDL spec

    AB: Arve and I briefly discussed Action #232
    ([28]http://www.w3.org/2008/webapps/track/actions/232) today in IRC
    (logger not working). His take is that this is not required for LCWD
    thus I want to drop it from the agenda. Any short comments/feedback?
    ... defer discssion

      [28] http://www.w3.org/2008/webapps/track/actions/232)

A&E spec: Action 290 - Review changes to HTML5 that may affect API and
Events spec and propose a way forward

    AB: Arve, what is the status of Action #290
    ... without Arve here, need to defer this

      [29] http://www.w3.org/2008/webapps/track/actions/290)?

A&E spec: Red Block issue in section 5.14 "ISSUE: do we need to do some
kind of URI normalization to check for equivalency?"

    AB: we will defer discussion on this too

    JK: the corresponding RFCs define the baseline
    ... the answer is Yes by RFCXXXX

    TR: are we talking about full URI refs?

    JK: the A+E spec defines valid uri

    AB: without Arve, I'd like to defer discussion

    TR: OK: I'll make a note to follow this

Widgets URI spec: Widget instances and widget invocations

    AB: last week Robin submitted a proposal
    445.html) re widget instances and widget invocations. There was some
    ... but no consensus
    ... RB, what's the next step on this?

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

    <tlr> concerning 5.14, I'm comfortable with (a) restricting to URIs
    (not IRIs) here, and (b) byte-wise comparison of these

    RB: I can make a new set of proposals; I don't have a strong opinion

    MC: this is an interesting discussion

    <JereK> tlr, why not character-wise comparison?

    <tlr> because for URIs (not IRIs) that's the same

    <tlr> in other wrods, I meant character-wise

    <JereK> understood :-)

    MC: not sure how much behavior we want to specify

    AB: what advice are we giving Robin?

    MC: do we want copies of prefs, do we want to clone, ...

    <JereK> unless you had UTF-8 encoded URIs?

    MC: there are lots of issues

    RB: this stuff doesn't belong in URI spec

    MC: agree and doesn't belong in P+C either

    RB: T-Mobile has some ideas about lifecycle for widgets
    ... would be good to see their input
    ... I'll talk to them

    AB: that would be good
    ... I also agree these issues don't belong in URI spec nor P+C spec
    ... what's the next step with the URI spec?

    RB: still need to complete some Edits
    ... when do we want to publish this?

    AB: we can talk about this

    RB: I think P+C is a higher prio

    AB: agree

    RB: perhaps we should wait until after P+C is published

    AB: my pref is to wait; want to get P+C and A+E to LC before we
    publish URI spec

    RB: OK. I'll focus on P+C and A+E

    AB: good priorities

Widgets URI spec: Action 338 - "edit access element to take into
account OMTP feedback and Bryan's"

    AB: Robin is Action #338
    ([31]http://www.w3.org/2008/webapps/track/actions/338) completed?

      [31] http://www.w3.org/2008/webapps/track/actions/338)

    RB: this is completed
    ... and MC has added it to the spec

    AB: great
    ... Meeting Adjourned

Summary of Action Items

    [NEW] ACTION: barstow add the required attribute to the v2 feature
    list [recorded in

    [End of minutes]
Received on Thursday, 7 May 2009 14:37:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC