The draft minutes from the May 7 Widgets voice conference are
available at the following and copied below:
<http://www.w3.org/2009/05/07-wam-minutes.html>
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
Approved.
-Regards, Art Barstow
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Widgets Voice Conference
07 May 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0499.html
See also: [3]IRC log
[3] http://www.w3.org/2009/05/07-wam-irc
Attendees
Present
Art, Jere, Thomas, Andy, Mike, Marcos, Robin, Arve
Regrets
Josh, David
Chair
Art
Scribe
Art
Contents
* [4]Topics
1. [5]Review and tweak agenda
2. [6]Announcements
3. [7]P&C spec: Proposal to add "required" attribute to
<access>
4. [8]P&C spec: <access> element comments by Thomas
5. [9]P&C spec: I18N issue: case-sensitivity of locale
subdirectories
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
equivalency?"
12. [16]Widgets URI spec: Widget instances and widget
invocations
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
([19]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
499.html). One change is discussing Marcos' P&C ToDo List
([20]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
500.html) during the "3.e." agenda item. Any other change requests?
[19] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0499.html).
[20] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0500.html)
[ None ]
Announcements
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
([21]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/a
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/
2009AprJun/att-0444/00-part)
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
list
... any objections?
[ None ]
RESOLUTION: the "required" attribute will be moved to the v2 feature
list
<scribe> ACTION: barstow add the required attribute to the v2
feature list [recorded in
[22]http://www.w3.org/2009/05/07-wam-minutes.html#action01]
<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
element
([23]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
470.html). Earlier today Robin replied to Thomas
([24]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
504.html). Let's start with Robin ...
[23] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0470.html).
[24] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0504.html).
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
more
... 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
element
... Do people have insight if that distinticint exists with authors
todayh
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
frames.
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
... 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
policy
... 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
models
... 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
([25]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
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/
2009AprJun/0404.html)
<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
widgets)
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
([27]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
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
work.
... 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
work.
... #1 - priority #1
... and who?
... #1: prio #1 and Marcos
... anyone can help?
[27] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0500.html).
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
this
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
([29]http://www.w3.org/2008/webapps/track/actions/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
([30]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
445.html) re widget instances and widget invocations. There was some
followup
... but no consensus
... RB, what's the next step on this?
[30] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0445.html)
<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
[32]http://www.w3.org/2009/05/07-wam-minutes.html#action01]
[End of minutes]
