See also: IRC log
<Marcos_> fjh: none is here yet, call has not started
<darobin> I'm getting "is unavailable, please try your call later"!
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
<tlr> I'll be late
<tlr> other call running over
Date: 30 April 2009
AB: draft agenda submitted 29 April (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0405.html). Since then Robin requested some additions (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0438.html) and we will add those agenda items. Any other change requests?
[ None ]
Topics: Announcements
AB: June 9-11 f2f meeting is just 5 weeks away; please remember to register (http://www.w3.org/2002/09/wbs/42538/WidgetsLondonJune2009/). Any other short annoucements?
[ None ]
AB: on April 23 David submitted
some comments regarding the <access> element (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0291.html).
I haven't seen a reply. I think the gist of the comments is
that the spec is a bit under-specified regarding what the UA
will do with the information. Comments?
... David isn't present
RB: most comments are fine; I need to coordinate the text with MC and that should be it
AB: I agree they seemed to make sense; think a NOT is missing in the 4th bullet
RB: I think the idea is the security policy takes precedence over the contents of the access element
AB: so RB and MC will add text to the ED, right?
RB: yes
BS: I have some questions about
the access element
... the way it is described; uses IRIs
... is this limited to HTTP only?
... what about other schemes such as FTP or UDP
RB: any scheme that uses URIs
BS: this element affects netwwork
access by any method
... regardless of the scheme
RB: yes, good point
AB: do you understands BS' issues well enough to relfect them in the spec?
RB: yes
AB: anything else on this topic?
BS: I will send an email about this element to the list
AB: can you take an action to do that by May 4 at the latest?
BS: yes
<scribe> ACTION: bryan submit an email to public-webapps re the <access> element [recorded in http://www.w3.org/2009/04/30-wam-minutes.html#action01]
<darobin> ACTION: Robin to edit access to take into account OMTP feedback and Bryan's [recorded in http://www.w3.org/2009/04/30-wam-minutes.html#action02]
AB: last week Marcos provided a short introduction to L10N model he proposed (http://dev.w3.org/cvsweb/2006/waf/widgets/i18n.htm), including his preferences for various proposals. Although some of us asked for Use Cases and Requirements to substantiate and clarify the proposals, they have not been provided. So far, preferences for the proposals have been submitted by at least Robin (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0409.html), AndyS (h
So far, preferences for the proposals have been submitted by at least Robin (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0409.html), AndyS (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0436.html), Francois (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0350.html) and myself (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0269.html).
AB: A1 vs A2; most people prefer
A2
... any objections to A2?
[ None ]
AB: B proposals; 3 for B1 and 2
for B2
... what are the benefits of B1, Marcos, briefly?
MC: support the use case where
people speak more than one language
... or more than one dialect of a language
RB: it also models HTTP's lang support
AB: any objections to B1?
[ None ]
RESOLUTION: L10N
proposal A2 is agreed
... L10N proposal B1 is agreed
AB: C proposals; there were 2
votes for C1 and Francois preferred C3 but qualified that
... MC, what is you take on this?
MC: my new pref is for C3, no
longer C1
... Francois' response convinced me
... or perhaps a modfied version of C3
AB: any other comments?
RB: I'm fine with C3
AB: any objection to agreeing on C3?
[ None ]
RESOLUTION: L10 proposal C3 is agreed with a few minor mods
AB: next is the D set of
proposals
... we have 3 votes for D2 and no other preferences were
submitted
... any comments about the D set of proposals?
... hearing none. Any objections to agreeing on D2?
[ None ]
RESOLUTION: L10N proposal D2 is agreed
AB: the E proposals
... MC prefers E1; Robin doesn't like either; Francois says E2
but not sure he understands the proposals real well
... any comments?
<tlr> zkim, mute me
RB: I think E, F and G can be addressed with the same approach
<darobin> RB: basically if we define a URI mapping for the widget: URI scheme such that it resolves to representations (files) in the widget archive, and that makes locales invisible — which addresses all issues at once
TR: whatever we do to map URIs to
files need consistency b/w sig and l10n piece
... I'm not opppsed to this but must think about impact of
signature model
... need to think about the addressing issue when considering
these proposal
RB: shoudn't the sig be at the file layer and nothing to do at the resolution layer
TR: that may be the right soln;
but must make sure it really works
... must be very careful; not sure we've done all the
work
... if the two can be separated that would be good
<tlr> the main point is that signatures expect URI references there.
MC: I don't yet understand either TR's proposal nor RB's proposal
<tlr> Relative URI references in there might lead to funny errors.
<tlr> so, careful
<tlr> that's one of the reasons for a widget URI scheme.
<darobin> I think that for all intents and
<darobin> purposes, the user agent should behave as if content from the most
<darobin> specific locale had been copied into less specific locales recursively
<darobin> until they are copied to the root, and the locales directory is
<darobin> discarded.
MC: yes, that is one of the proposals I made
RB: it is sorta' like one of your proposals but not exactly
MC: ok, so maybe they are the same
<darobin> also:
<darobin> The justification behind this approach is that: a) locales should be
<darobin> transparent, and b) there is no requirement to have the widget URI map
<darobin> *directly* unto the widget's structure. In fact, it is probably best
<darobin> if it's not possible inside locales/en/index.html to go "<a href='../
<darobin> fr/index.html'>Frog version</a>".
RB: the idea is to change the base URI
MC: the reason we proposed
rewriting the URI is to get predictability
... but effectively, it should work as Robin is proposing
... want developer to easily know where files come from
... I'm OK with this proposal
... we do have some concerns it will cause confusion
... but if there is consensus to go that route I am willing to
update my proposal
RB: it effect F and G as well
MC: yes agree
<tlr> I think I'm resigned to this.
RB: you wouldn't have missing localized content in my model
MC: yes, true; and we wouldn't need XML Base
RB: yes, correct
AB: what about the G proposal MC if you went with RB's proposal?
MC: if we go with RB's propsal, we eliminate E, F and G and they become a single proposal
AB: that certainly sounds like a
win to me
... any other comments?
<tlr> +1 to robin
<tlr> that's the context in which it needs to be discussed
<marcos> proposal 1: pretend to copy everything to the root of the widget. 2: Pretend everything has been copied in the locale folder.
[ Pause while MC' enter's proposal into IRC ]
RB: this part of the proposal could go in the widget URI spec
<darobin> RB: I think that this could go into the wURI document
MC: I prefer Option #1
RB: I prefer that option too
AB: any other comments?
RB: proposals A thru D would go
in P+C spec
... and the E+F+G would go in the URI spec
MC: I agree with RB's plan above
AB: any comments about this
plan?
... I support it
... what about time frames RB and MC?
RB: I can do it by May 5
MC: I can it by May 7
AB: propose E+F+G proposal from
Robin be merged into a single proposal and added to the Widget
URI spec
... any objections?
RESOLUTION: E+F+G proposal from Robin will be merged into the Widget URI spec
AB: thanks to Marcos for working on this doc!
AB: on 28 April Thomas identified (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0370.html) two high priority security concerns regarding what I called "core" widget specs: 1) How are relative URI references absolutized? and 2) How do widgets interact with the HTML5 security policy? Thomas, would you please start with a short introduction to the first issue?
<tlr> This translates into "the widget URI spec"
TR: the most important thing is
what goes in the Widget URI spec
... the second question is the more critical question
... e.g. HTML5 frame communication
... that will be used by widgets
... need to get agreement on the origin property
... the current approach is trying to solve both of these
problems at once
... we need to get the URI spec right!
... we can defer this discussion to the URI spec agenda
topic
... must get origin and addressing right
<tlr> ACTION: thomas to review <access> element by Tuesday [recorded in http://www.w3.org/2009/04/30-wam-minutes.html#action03]
RB: would you please review the <access> element by May 4 / 5?
AB: last week there was a
discussion about the Storage interface (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0301.html)
and whether or not
... the spec should say something about widget instances and
Storage interface
Arve: Storage interface should be
instantiated per widget
... that has always been clear to me
... an issue is the origin
RB: we have been talking about this in the context of the URI scheme
MC: when we hit URIs we hit
origin; they can't be separated
... there is a dependency of Storage and origin
... it is based on identity
... must make sure the storage area is not shared
... we want widgets to have their own storage
... instance must not share storage, cookies, etc.
RB: you mean instances of the same widget?
MC: yes
RB: if the origin is constant after it is installed, if it is run, stopped, run again should have same origin
TR: must separate addressing and origin
RB: we have been having some related discussion with Anne
TR: could have some shared
storage
... I hear Arve state a requirement that can be easily
solved
... but I think Guido has a req for shared storage
Arve: I don't get the req for
shared storage
... I can understand shared data
... but not shared Storage
<darobin> http://www.w3.org/mid/644AF4A6-9D1F-4D99-ACEB-E3A68398AA6E@berjon.com
<scribe> ACTION: [recorded in http://www.w3.org/2009/04/30-wam-minutes.html#action04]
<scribe> ACTION: Guido submit shared storage requirement to public-webapps [recorded in http://www.w3.org/2009/04/30-wam-minutes.html#action05]
TR: I agree with Arve; the
conversation I had with Guido was about a different
requirement
... if everyone is OK with per-instance storage, that is OK
with me
... just wanted to let you know a shared Storage req may come
up
Arve: we need a good definition of instance
<trackbot> Sorry... I don't know anything about this channel
<trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
trackbot, this is WebApps
<trackbot> Sorry, ArtB, I don't understand 'trackbot, this is WebApps'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
trackot, associate this channel with #webapps
<tlr> tracbot, this is webapps
trackbot, associate this channel with #webapps
<trackbot> Associating this channel with #webapps...
AB: on 24 April Rainer submitted some comments against the A&E spec (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0335.html). There has been response. Marcos, Arve - what is your position on these comments?
Arve: these comments are just bug reports; all proposed changes are fine with me
MC: I haven't looked at those comment yet
AB: I'm trying to get a sense of whether any of these comments are considered substantial
Arve: no, I don't think so
BS: I sent the access element comments to the list so please close that action
AB: let's take this to the mail list. Arve, Marcos - would one of you please agree to an action to send a list of open issues and actions that must be addressed before we can publish a LCWD of the A&E spec? Would be best if you would include proposals on how to address the issues and action.
MC: Ok
AB: earlier today Robin requested some additions (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0438.html) to the agenda. Robin, what do you want to discuss first?
<darobin> "who volunteers to handle the the URL path to Zip relative path mapping (and back)"
RB: I'll paste in something MC
noted
... we need to assign an Action so someone can take this
... MC, can you take it?
MC: yes I can take it but we'll
need to work on it together
... must make sure what we do is in accordance with IRI
TR: please do not define a way to decode an IRI
MC: we must define how to do the mapping though
<darobin> "do we need UUIDs in widget URIs"
<darobin> http://dev.w3.org/html5/spec/#origin
RB: I think we can do without
them
... use HTML5 mechanism
... if we drop UUID we can use that
<marcos> the uri scheme looks like widget://path
RB: based on discussions with Anne and MC, I think we can do this
TR: it is probably useful to say what the origin looks like e.g. large random num
<darobin> HTML5 says "globally unique identifier"
TR: if we need to have instance
to instance comm
... we will need a widget specific uri scheme
[ Scribe is not getting TR's comments .... ]
<arve> me neither
TR: two probs: how to identify something in the package
<darobin> tlr's comments are largely at: http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/2009Mar/0000.html
TR: also need to ref things within the pack from outside the package
RB: need to separate two
things
... inter widget comm is dropped for v1
RESOLUTION: inter widget communication is dropped for v1
<marcos> +q
<marcos> -q
Arve: why do you want to use a
widget to directly access another widget's package?
... do you want to access the resources in a widget ?
TR: want to understand the
relationship between html5 offline apps and widgets
... want same app code from a web app to work with a
widget
... the addressing part is critical
... don't want an artifical boundary between web apps and
widgets
... if we use a diff addressing scheme there will be
problems
MC: but some web apps have a sec model that just won't work with widgets
TR: want to avoid the artificial
boundary
... can we make the widget model and web app model
converge-able? I think we can if we get the addressing
right.
<marcos> <content src="http://gmail.com/#inbox" />
MC: we don't allow resources to
address a web page e.g. via the <content> element
... we need to keep things relatively constrained for v1
RB: I think there is transition
path from the model we're thinking and the one TR wants
... think the bridge could be there and v2 can move to the new
model
TR: most v2's are mythical
AB: what's the next step?
... do we want to get a FPWD in May?
RB: yes
TR: I am willing to work on the
redirection layer
... if RB has a migration path in mind, I'd like to understand
it more
... for sig and l10n we do indeed need something like the URI
scheme
AB: Meeting Ajourned
<arve> I wasn't kidding when I said I was publishing the pics: http://www.flickr.com/photos/arvebersvendsen/3488989846/
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found ScribeNick: ArtB Found Scribe: Art Present: Art Mike Robin Marcin AndyB Frederick Marcos Arve Bryan Thomas Regrets: AndySledd Mark David Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0405.html Found Date: 30 Apr 2009 Guessing minutes URL: http://www.w3.org/2009/04/30-wam-minutes.html WARNING: No person found for ACTION item: [recorded in http://www.w3.org/2009/04/30-wam-minutes.html#action04] People with action items: an bryan email guido requirement robin shared storage submit thomas[End of scribe.perl diagnostic output]