- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Thu, 2 Oct 2008 08:18:49 -0400
- To: public-webapps <public-webapps@w3.org>
The minutes from the October 2 Widgets f2f meeting are available at
the following and copied below:
<http://www.w3.org/2008/10/02-wam-minutes.html>
WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before October 9 (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
02 Oct 2008
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-webapps/
2008OctDec/0001.html
See also: [3]IRC log
[3] http://www.w3.org/2008/10/02-wam-irc
Attendees
Present
Art, Marcos, Mark, David, Adam, Arve, Claudio, Benoit, Josh,
MikeSmith
Regrets
Thomas, Nick
Chair
ArtB
Scribe
Art
Contents
* [4]Topics
1. [5]Agenda tweaks
2. [6]Annoucements
3. [7]Widgets Core API and Event spec
4. [8]Preferences API
5. [9]P&C feature element and access element
6. [10]P&C <span> element
7. [11]Dig Sig spec
* [12]Summary of Action Items
_________________________________________________________
<arve> sorry, will call in in 15 seconds
<timeless> s the meeting number
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
Date: 2 October 2008
Agenda tweaks
AB: any change requests?
[None]
Annoucements
AB: registration deadline for Mandelieu is now Oct 12
... Mandelieu agenda is still a WIP
... Security WS in December
MC: I intend to submit a Position Paper
AB: pub moratorium is Oct 13
Widgets Core API and Event spec
AB: what's the status Arve?
Arve: I just committed a new version to CVS
... [13]http://dev.w3.org/2006/waf/widgets-api/
... we need to talk about using HTML5 APIs instead of get/set prefs
... does the refs section need to be complete?
[13] http://dev.w3.org/2006/waf/widgets-api/
MC: I think you can leave it open
<arve> [14]http://dev.w3.org/2006/waf/widgets-api/Overview.src.html
[14] http://dev.w3.org/2006/waf/widgets-api/Overview.src.html
AB: anything else blocking pub?
... may want to provide a bit more context for the red blocks
BS: I agree
Arve: yes, I can do that
BS: a list of issues would be helpful; gives the reader a sense of
what's going to be done
Preferences API
AB: Marcos made a propsal on the list
[15]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/
0736.html
[15] http://lists.w3.org/Archives/Public/public-webapps/
2008JulSep/
<marcos>
[16]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/07
36.html
[16] http://lists.w3.org/Archives/Public/public-webapps/
2008JulSep/0736.html
JS: I like the idea of dropping the APIs and using HTML5
<arve> +1
MC: the basic problem is we are defining an API that is already
defined in HTML5
... this will cause probs for developers
... we don't want to have two different APIs
... I recommend we use HTML5
... It has already been implemented in some browsers
Arve: I quite agree with Marcos
... but we need to mention some stuff
... if we are going to do that
... For example, need to make it clear each widget instance has its
own cache
MC: agree we may need to do some tweaks
... need to understand the overlaps of our reqs with HTML5
Arve: need to add some explicit requirements for the UA
... we may need to define a UA context
... that says something about caching, redirects, etc.
... Stuff that is beyond the scope of HTML5
... The interface is defined in HTML5 but not the implications in
our context
JS: regarding reqs, need to also think about the need for storage to
grow
<arve> We need to define: Widget instance caching context, widget
instance security context, widget instance storage context
AB: where would this stuff be documented?
Arve: in the P&C spec
MC: I'm fine with that
AB: agree this contextual info would be good to document
... but who is going to create that documentation?
... does Opera have some documentation we could review?
Arve: another option is to go back to Opera's security input and
move it forward
<arve> what we're saying currently is:
<arve> Separate widget instances share no information at all.
Specifically:
MC: yes, maybe this information should not in P&C but rather in a
separarte doc such as Widgets Sec Model
<arve> A cookie set by a widget instance, or by a URL loaded by a
widget (eg through XmlHttpRequest) is visible only to that widget
instance, never to any other instances or to documents loaded into
the browser in any other way.
<arve> If a URL loaded by a widget requires HTTP authentication then
authentication must be performed on behalf of that widget instance;
the authentication is not shared with other widget instances or with
URLs loaded into the browser in any other way.
<arve> A set of settings for a widget instance is shared with no
other widget instances.
<arve> Other persistent storage mechanisms, such as those defined in
HTML must not share data with other widget instances, or with the
storage context in the web browser.
<arve> Cache files or cache indexes are not shared with the web
browser, or with any other widget instance
BS: I think this type of info is good to have
AB: I tend to agree with Marcos this information should not be put
in the P&C spec
BS: in the advertising context, cookies are a concern; don't want
any breaches
AB: propose we drop our own storage APIs in the API spec and use
HTML5's storage APIs
... any objections?
[None]
RESOLUTION: we will drop the storage APIs in the API and Events spec
and use the HTML5 storage APIs
CV: advertising in Widgets may require more discussion on storage
APIs
P&C feature element and access element
MC: currently we have <access> to state pref for network access,
plugins, etc.
... that functionality is replicated by <feature>
<marcos> in <access> we had: <access network="true" etc....>, Dom
proposed we change it to <widget access="network plugins etc..">,
then Arve wanted to replace all that with <feature
id="[17]http://www.w3.org/widgets/network">
[17] http://www.w3.org/widgets/network
MC: I discussed this with Arve
... Dominque recommended access just be an attribute on <widget>
... we can also use URIs on <feature>
... this give much more fine-grained control
... Yahoo provides more control but not using URIs
Arve: Opera provides fine control too
... if we have URIs we can extend easily
AB: any other feedback?
MC: also could be used to define device capabilities
... e.g. using fragment ids or query strings
CV: we're not sure network access and feature are at the same level
... we think access should be kept
... something like network access is important, especially for
mobile operators
Arve: I think our proposal can be used to provide the exact same
info that can be specified in <access network=@@@">
AB: since this is the first time we've seen this proposal, I don't
think we should make a decision today
... Would like MC and/or Arve to submit their proposal to the list
for feedback
Arve: agree; this is a strawman proposal now; we need feedback
CV: I agree we need to have some discussion on this
... need to make sure it covers all of our use cases
MC: I agree with Claudio
... think <access> can be useful as well as <feature>
AB: what are your thoughts on this Marcos?
MC: I can create a proposal for a model to address this discussion
and the requirements
P&C <span> element
AB: the I18N WG submitted some comments on the <span> element
... what is the status Marcos?
MC: we have to do something
<marcos>
[18]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/06
26.html
[18] http://lists.w3.org/Archives/Public/public-webapps/
2008JulSep/0626.html
MC: options are to add <span> or the ITS spec
... My concern is about mandating support for ITS
AB: I tend to share that concern about ITS support
<marcos> MC: for example <description> bla bla <its:span> blo
blo</its:span> </description>
AB: do we just reuse its:span?
MC: yes, but supporting ITS adds a lot of complexity
AB: should we punt on this for v1?
MC: I can do some investigation on this
... I think it's OK to drop it for v1 and plan to add it to v2
... we already have a number of I18N features
AB: is anything hearing mandatory support for ITS for v1?
JS: I'm worried about the implementation burden about this
... if we support Unicode we should be OK for v1
... Also could make authoring more difficult
<marcos> this is what Felix said: "To keep simplicity for Widgets
1.0, you could say in your conformance
<marcos> description that a Widgets processor has various options to
deal with
<marcos> the <its:span> element (or more in general: the ITS
namespace) and its
<marcos> attributes: ignore them or process them
<marcos> "
JS: It would be real helpful if we had a validator for a manifest
<marcos>
[19]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/06
26.html
[19] http://lists.w3.org/Archives/Public/public-webapps/
2008JulSep/0626.html
MC: I can codify Felix' recommendation
AB: I can live with that for v1
... I propose Marcos codify Felix' recommendation to address the
span issue
... any objections?
[None]
RESOLUTION: Marcos will codify Felix's recommendation to address the
span issue
([20]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0
626.html)
[20] http://lists.w3.org/Archives/Public/public-webapps/
2008JulSep/0626.html)
Dig Sig spec
AB: status from Mark or Marcos?
MC: I haven't been working on it
MP: neither have I
... I have done some stuff on update and sent it to Marcos
JS: should we invite XML Sig WG?
AB: I've already done that - Tues Oct 21 11:00-12:00
<scribe> ACTION: Barstow ping the XML Sig WG re the questions we
sent to them last week [recorded in
[21]http://www.w3.org/2008/10/02-wam-minutes.html#action01]
<trackbot> Created ACTION-253 - Ping the XML Sig WG re the questions
we sent to them last week [on Arthur Barstow - due 2008-10-09].
MC: David, are you going to send us some info OMTP re the DigSig
spec?
DR: I'll follow-up with Nick
AB: Meeting Closed
Summary of Action Items
[NEW] ACTION: Barstow ping the XML Sig WG re the questions we sent
to them last week [recorded in
[22]http://www.w3.org/2008/10/02-wam-minutes.html#action01]
[End of minutes]
Received on Thursday, 2 October 2008 12:20:06 UTC