See also: IRC log
<arve> sorry, will call in in 15 seconds
<timeless> s the meeting number
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
Date: 2 October 2008
AB: any change requests?
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
AB: what's the status Arve?
Arve: I just committed a new
version to CVS
... we need to talk about using HTML5 APIs instead of get/set prefs
... does the refs section need to be complete?
MC: I think you can leave it open
AB: anything else blocking
... 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
AB: Marcos made a propsal on the list http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/ 0736.html
JS: I like the idea of dropping the APIs and using HTML5
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
... 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
... 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?
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
MC: currently we have
<access> to state pref for network access, plugins,
... 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="http://www.w3.org/widgets/network">
MC: I discussed this with
... 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
... if we have URIs we can extend easily
AB: any other feedback?
MC: also could be used to define
... 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
... 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
AB: the I18N WG submitted some
comments on the <span> element
... what is the status Marcos?
MC: we have to do something
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
... 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
JS: It would be real helpful if we had a validator for a manifest
MC: I can codify Felix' recommendation
AB: I can live with that for
... I propose Marcos codify Felix' recommendation to address the span issue
... any objections?
RESOLUTION: Marcos will codify Felix's recommendation to address the span issue (http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0626.html)
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 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
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Art Found ScribeNick: ArtB Present: Art Marcos Mark David Adam Arve Claudio Benoit Josh MikeSmith Regrets: Thomas Nick Agenda: http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0001.html Found Date: 02 Oct 2008 Guessing minutes URL: http://www.w3.org/2008/10/02-wam-minutes.html People with action items: barstow[End of scribe.perl diagnostic output]