- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Fri, 12 Jun 2009 06:42:39 -0400
- To: public-webapps <public-webapps@w3.org>
The draft minutes from the June 9 Widgets f2f are available at the
following and copied below:
<http://www.w3.org/2009/06/09-wam-minutes.html>
WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before 18 June 2009 (the next
Widgets voice conference); otherwise these minutes will be considered
Approved.
-Regards, Art Barstow
[1]W3C
[1] http://www.w3.org/
Widgets F2F Meeting
09 Jun 2009
[2]Agenda
[2] http://www.w3.org/2008/webapps/wiki/
WidgetsLondonJune2009#Agenda
See also: [3]IRC log
[3] http://www.w3.org/2009/06/09-wam-irc
Attendees
Present
Benoit, Mike, Josh, Jere, Art, Robin, Marcos, AndyB, DanA,
David, Laura, Marcin, Bryan, Magnus, Richard, Frederick,
Thomas, SteveL
Regrets
Chair
Art
Scribe
ArtB, Art, Bryan, Art, Mike, Dan
Contents
* [4]Topics
1. [5]Introductions
2. [6]Confidentiality of Minutes
3. [7]Agenda Tweaking
4. [8]Packaging and Config spec
5. [9]Localization
6. [10]Localisation
7. [11]Access Requests Policy
8. [12]URI Scheme
9. [13]P+C
10. [14]Updates
11. [15]Discussing Brian's input
* [16]Summary of Action Items
_________________________________________________________
Introductions
AB: Arve had a last minute cancelation and will not attend
... registered but not here yet: Paddy, Richard Tibbett, Jonathon,
Nick and Ivan
Confidentiality of Minutes
AB: all of the minutes will be Public
... any questions about that?
[ None ]
Agenda Tweaking
AB: Agenda:
[17]http://www.w3.org/2008/webapps/wiki/WidgetsLondonJune2009#Agenda
_Items
... we will start with P+C this morning
... talk about high priority issues
... from 13:00-15:00 today we will talk about Security Model
vis-a-vis <access> and the WARP document
[17] http://www.w3.org/2008/webapps/wiki/
WidgetsLondonJune2009#Agenda_Items
Packaging and Config spec
AB: spec: [18]http://dev.w3.org/2006/waf/widgets/
... other than feature and L10N are there other hot topics?
[18] http://dev.w3.org/2006/waf/widgets/
MC: no not really
AB: Henri's
[19]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/06
99.html
... comment about clarifying purpose of feature
... I think the way we have documented feature in P+C is OK
... but there are questions about what a UA will do with the data
... what is our plan to specify the behavior?
[19] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0699.html
<scribe> Scribe: Art, Mike
<MikeSmith> Scribenick: MikeSmith
ArtB: what work remains to be done for <feature>?
Marcos: I don't think anything more needs to be done.. it's
specified.
ArtB: Anybody disagree with that?
Marcos: Biggest impact is on BONDI, so it matters most if it is OK
as-is for them.
... I think it meets the BONDI use cases.
Robin: If OMTP is OK with it, I'm OK with it.
... I'm happier with use cases that don't require it, because that's
more Web-like.
David: In the absence of a more proper security model, we still
support this.
... We are happy for [the editors] to take the lead on this.
Marcin: We just want it to be stable.
ArtB: Is OMTP going to extend it after?
Bryan: We may add some semantics, but we are not planning to add
additional attributes.
David: If we have a policy mechanism -- some way of regulating
access for the user -- then this element is actually redundant.
Marcos: So it really is more of a stop-gap for now
ArtB: Anybody else have anything to add on this topic?
PROPOSED RESOLUTION: The group agrees that the <feature> element as
defined in the LC WD is complete.
ArtB: Any objections?
[none]
RESOLUTION: The group agrees that the <feature> element as defined
in the LC WD is complete.
Marcos: [discussing issue of case sensitivity in localization
system]
[discussion about mailing-list discussions from last couple days]
Marcin: [talking specifically about recent BONDI decisions around
requestFeature() and widgets vs. Web pages]
Marcos: as far as requestFeature(), as this point, it does not exist
in the Widgets specs.
David: Yeah, we are still just discussing it within OMTP.
Marcin: [explaining background on submission of BONDI specs for
review within W3C]
Bryan: One question is: Do we have the ability to author [a
document] as both a Web page and a Widget.
... Another question is around dynamically loading.
Marcos: I think the DAP WG will be the one that needs to answer
that.
timeless_mbp: because of localization and path constraints,
currently you won't be able to [drop a widget into a page and have
it work]
Marcin: In theory, for this case, the widget UA should be behaving
conceptually in the same way as an HTTP server.
ArtB: What I see is that David announced "we are now done, please
review"
David: So if it's the view of the WebApps WG that getFeature() is
more correctly specified within the DAP WG, then we would follow
your lead on that.
Marcos: The problem is that it currently seems to make assumptions
about a particular architecture.
Robin: Yes, the feedback you are likely to get from browser vendors
is that as currently specified, it does not match with browser
architecture, and there are other ways to solve the problem.
Marcin: The whole BONDI initiative came about because of need for a
"fast standard".. but BONDI operates under many of the same
principles as the W3C.
... The expectation is that everything that has been produced by
BONDI will be reviewed within W3C... but none of what BONDI has
produced thus far is considered a "must".
David: so to step back, we don't have DAP yet, so we need a stop-gap
in the meantime to address the issue
Localization
<scribe> Scribenick: Bryan
Localisation
<ArtB> Jere's comments:
[20]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/07
23.html
[20] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0723.html
<ArtB> P+C ED: [21]http://dev.w3.org/2006/waf/widgets/
[21] http://dev.w3.org/2006/waf/widgets/
Jere: comments were mostly editorial
<ArtB> Macros' response to Jere:
[22]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/08
24.html
[22] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0824.html
Marcos: the main issue was case sensitivity in localisation
... effectively what we have for localisation is a language list and
a list of folders. the algorithm is to do a string match, case
sensitively.
... the solution is to match everything in the local part of a path
case-insensitively
Josh: forcing failure for anything other than lowercase is another
option
... it is easy to write an algorithm than discards anything that
does not match with lower case
Marcos: we need to ensure we don't violate ISO specs re case
requirements
Robin: we don't need to follow the ISO specs
Josh: the widgets spec is not defining a language code thus we don't
have to follow rules for languages
<Marcos> RESOLUTION: in the spec, we will mandate that language tags
for locale folders be in lowercase form (relevant to authors). Only
locale folders in lowercase form will be matched by the widget user
agent.
Jere: is it possible to have upper-case folders present anyway, and
the sensisble thing is to fold it to lower case and continue
Robin: the sensible thing to do is to discard folders that are
non-conformant
Jere: compromise, allow any case as long as it's unique and then
treat it as lower case
Robin: in a case insensistive file system, how to handle if the
language tag folders are not unique - the easiest is just to kill
them
Bryan: what is the downside of ensuring uniqueness and case folding?
Josh: it can cause confusion as the author was expecting one
behavior and gets another
<timeless_mbp> DRAFT RESOLUTION: any folder as a direct child of the
locales folder whose name is not entirely in lowercase will not be
reachable by any means.
David: is there any existing requirement mandating lowercase in the
specs?
Josh: there is precedent in other specs to require case sensitive
matching
No objections.
RESOLUTION: any folder as a direct child of the locales folder whose
name is not entirely in lowercase will not be reachable by any
means.
Art: are there still some comments on localisation outstanding?
Jere: some editorial comments, the email exchange is ongoing
Marcos: it was proposed to reshuffle the content which is now done,
e.g. the localisation is now in one area. Need to do a read-thru to
ensure good flow
... there's nothing else that is editorial - the question on
xml:lang needs to be resolved
Josh: in 5.3 the locale/folder needs to not reference the folder
name - it needs to be called "locale folder" or something that makes
it clear what we are referring to
<timeless_mbp> not locale folder since that's taken
<timeless_mbp> but locale-folder-name which might reference BCP47
with a prose restriction to lowercase, or a copy of BCP47 with the
BNF restricted to lowercase
Marcos: to fix this, we need to change elements of the ABNF if we
were to take the language tag from bcp47
Robin: it is better to restrict it in prose rather than ABNF
<timeless_mbp> ok :)
Jere: the issue raised re xml:lang values being unique, does this
come from I18N best practices?
Michael: from HTML5, for authoring we have encouraged people to move
away from xml:lang
Robin: that's because HTML4 had a lang tag and there is thus
duplication. in our case we are starting from scratch
... for widgets, we define the processing model and it will clarify
how to handle the set of xml:lang entries
Marcos: the entries are specified to be in document order
Marcin: does this work related to ITS?
Marcos: it relates since the ITS affects to to handle character
sequences
Jere: the issue is resolved since the description will define the
handling
Marcos: in the 1st example of step 5, we need to make the language
sequence consistent, and to ensure what is being ilustrated is
correct
... the use case is the user has entered the language preferences,
and the widget user agent ensures the list of languages is per the
spec, and to avoid confusion we need to be clear on how it does that
Benoit: is there a point inthe processing model, how specific the
selected language needs to be
Marcos: there are those who want a specific dialect over the generic
or another dialect
Josh: there are those that would prefer english for example to an
unknown dialect of their language
Marcos: the question is how to eliminate repetitions/ambiguity in
the selected list
Josh: the processing should enable e.g. avoidance of random untagged
english if another language is preferable
Art: are there any objections to the processing model presented on
the screen?
<Marcos> Draft Resolution: treat language tags in the order they
appear in the UA Locale list, instead of treating them as
recommended by BCP47.
<Marcos> "en-us,en-au,fr,en"
<Marcos> Would become:
<Marcos> "en-us,en-au,fr,en"
<Marcos> "en-us,en-au,fr"
<Marcos> Would become:
<Marcos> "en-us,en-au,en,fr"
Josh: the example does not yet quite meet the draft resolution
Art: it's a question for Josh and Marcos to figure out how to word
in the spec
Resolution: treat language tags in the order they appear in the UA
Locale list, instead of treating them as recommended by BCP47.
Jere: an outstanding issue is the runtime resolution of the
resources, we can discuss that later
<ArtB> Scribe+ DanA
<darobin> do you see me?
<tlr> darobin, if you could dial into the bridge?
<DKA> Scribe: Dan
<DKA> ScribeNick: DKA
[back from lunch]
Access Requests Policy
Art: I'm projecting the June 5 version of the WARP document.
... We want to use this time to go through this document and solicit
comments. One question I'd like to pose is - is there consensus to
publish the document as FPWD?
<ArtB> [23]http://dev.w3.org/2006/waf/widgets-access/
[23] http://dev.w3.org/2006/waf/widgets-access/
Art: over to Robin for a quick walk-through
Robin: To give some background - this spec defines the access
element which was previously in PnC and got dropped out to a
separate spec rather than delay PnC.
... It follows typical structure.
... It has a simple model whereby the access grants access within
the widget execution scope to certain network resources but anything
that is outside the widget executtion scope
... does not have the same levels of access.
... The advantage: it maintains protection to sensitive APIs because
you can't communicate across iframe boundaries. etc...
Bryan: clarify?
Robin: if you have a widget with access to the address book (e.g.)
and in a separate context you have an access element that grants it
to load something from a foreign host then this context will not
have access to the address book.
<Zakim> Thomas, you wanted to note that it *can* communicate, but
the widget is able to control that access
Thomas: to clarify - a very limited amount of communication is
possible using APIs like post message... you do have cross-origin
communication within a browser. But this is tightly controlled by
the widget. The important point is that the widget cannot script the
iframe and the iframe cannot script the widget.
... This gives us a very well-defined interface and puts relatively
strict limits - doesn't give access from the web to "risky" APIs
yet.
Robin: there's no information leakage unless you've trusted an evil
widget.
Josh: With an iframe, to a normal user, you can load a javascript
URL that executes arbitrary code in the context of that web page....
Assuming the widget will not be allowed to do that.
... That code executes in the context of the iframe. It doesn't have
access to the widget but it has total access to the iframe.
Robin: Yes.
Josh: So it's not a very tall wall in that direction.
<Zakim> timeless_mbp, you wanted to verify that the widget can't
load javascript:scriptWidget() in the iframe
Robin: The rest of the spec is the syntax and the processing model.
... There have been two messages so far with editorial comments
which I'll apply before we publish.
[discussion of the comments from Thomas from today]
<ArtB> TLR's comments today:
[24]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/08
59.html
[24] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0859.html
Thomas: Point 3 in my notes - I continue to not be convinced that
it's a good idea to build a new model within the widget that
contains inline content.
... other points raised are editorial in nature.
... [discusses his additional comments]
... To give an example, the document talks about parsing in document
order but this doesn't have anything to do with this specification.
... [suggests compressing the parsing instructions]
Robin: WRT point 2. I was thinking that it shouldn't say anything
about HTML5 security policy but should just say that it uses the
security policy "of the host language being used" which removes the
dependency on HTML5.
Josh: there are 2 parts that reference HTML5.
Art: Any objections to that proposal?
Josh: The other HTML5 reference needs to point to some other thing.
Bryan: [clarify web application scope?]
<ArtB> [ Discuss "The widget execution scope is the scope (or set of
scopes, seen as a single one for simplicity's sake) being the
execution context for code running from documents that are part of
the widget package. Note that a script loaded from an external URI
into a document that is part of the widget is running in the widget
execution scope. " ]
Bryan: If I load a script off of the Web and I run that within a
container that is part of the html page that the widget as defined,
is that web scope or widget scope?
Robin: If the access has been granted by the access element then it
is running in the widget context.
Bryan: if I load further scripts then those have the same
permissions?
Robin: Yes.
Bryan: Where do we transition to the Web scope?
Robin: If you have another document - like an iframe - which has an
origin that is not inside the widget.
<timeless_mbp> for my reference, CORS is
[25]http://www.w3.org/TR/cors/
[25] http://www.w3.org/TR/cors/
Robin: The case of bringing in script from the web relys on the
access element having granted that access [in the widget context] so
subject to the access policy.
... A widget can contain multiple documents... All of those
documents run within the widget scope. If one of those runs a script
from a URI on the web then that script is running in the widget
context.
... We don't want to constrain the security models for others within
this spec.
... We don't want to break the Web.
Bryan: Suggests inserting a [zzzt zzzt]
<tlr> [awfully noisy call right now]
<darobin>
[26]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/07
32.html
[26] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0732.html
Bryan: Suggests inserting a concrete example in the document to
clarify.
Frederic: I support having more details in the examples - e.g. the
airline flight tracker. If you have a feature that allows access to
the camera ...
<timeless_mbp> Zakim: mute [london]
Frederic: it talks about feature-enabled APIs in section 2. I assume
feature enabled then that feature applies to anything [in that
context].
Thomas: Any script that can control the widget execution context
would have access to that feature.
Robin: I will put a specific example in to clarify.
Frederic: This is truly for network access and not for anything else
(e.g. a URI to a feature).
Bryan: A local host URI such as a smartcard web server would be
covered.
[yes]
Robin: Your definition of a network resource is anything with a URI
that is referenced by DNS or IP.
[agreement]
<Zakim> timeless_mbp, you wanted to ask if <access
uri="[27]http://redirect.example.org"> and a widget has <iframe
src="[28]http://redirect.example.org/?http://somethingelse.com">
would be
[27] http://redirect.example.org/
[28] http://redirect.example.org/?http://somethingelse.com
Robin: If access says it's OK to access foo.com and you load foo.com
and it redirects to bar.com.
Josh: [advertisement for CORS
Thomas: Don't have an easy answer to the redirect question. Not
clear that CORS is the answer. The fundamental distinction we have
is ...
... just mixing redirects and origin determination could be a huge
security hole.
Frederic: We have the asterix which allows access to all assets -
could this become a problem?
Robin: this was debated before but not everyone was happy with the
solutiuon. But if you want to access something like google maps you
get a zillion subdomains...
Steve: There's no way to state that intent more explicitly?
Robin: if you enable foo.com and its subdomains then it could allow
access to an IP address in your internal network.
[consensus we need to fix the web or something]
Robin: a user agent would assign an opaque, unique, global
identifier to each instance.
Thomas: I suggest we leave this open because there is a proposal to
assign the same identifier to different widgets if they have been
signed with the same cert.
Robin: We remain silent.
Josh: What about multiple instances?
Robin: Currently undefined.
Thomas: We don't know right now - probably something we should leave
undefined at this time.
... When it comes to local storage they would have to take care of
not stepping on eachother's toes. That's the one [problem area I see
with multiple instances]
Art: where are we wrt FPWD?
<lewontin> Possible that device access security model might further
restrict access beyond same-origin.
<fjh2> I was the speaker asking about making intent more explicit...
<lewontin> This shouldn't affect anything in this spec explicitly.
Art: What kind of time-frame are you thinking?
Robin: I can do it this week.
Art: I'd like to give Robin the freedom to make those changes.
PROPOSED RESOLUTION: The WARP document modulo the changes Robin's
agreed to make is ready for FPWD.
[no objections]
RESOLUTION: The WARP document modulo the changes Robin's agreed to
make is ready for FPWD.
Robin: Short name?
Art: My recommendation is widget-access
[discussion on what to cover next]
URI Scheme
<ArtB> Spec:
[29]http://dev.w3.org/cvsweb/2006/waf/widgets-uri/Overview.html
[29] http://dev.w3.org/cvsweb/2006/waf/widgets-uri/Overview.html
<tlr>
[30]http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-uri/Overvie
w.html?rev=1.8&content-type=text/html;%20charset=iso-8859-1
[30] http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-uri/
Overview.html?rev=1.8&content-type=text/html;%20charset=iso-8859-1
<darobin> [31]http://dev.w3.org/2006/waf/widgets-uri/
[31] http://dev.w3.org/2006/waf/widgets-uri/
<tlr>
[32]http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-uri/Overvie
w.html?rev=1.8&content-type=text/html;%20charset=utf-8
[32] http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-uri/
Overview.html?rev=1.8&content-type=text/html;%20charset=utf-8
Art: Over to Robin.
<Marcos> [33]http://dev.w3.org/2006/waf/widgets-uri/
[33] http://dev.w3.org/2006/waf/widgets-uri/
Robin: This isn't up to date with the latest edits.
... I want to propose that the authority is a string that must be
ignored in this version. Paves the path forward for use of
signatures in future versions.
<Marcos> Scribe+ Marcos
<Marcos> ScribeNick: Marcos
RB: with the issues listed at the begining, plus a few other things,
we have enough to run with for version 1
<tlr> works for me
<tlr> certainly ready for FPWD
JS: what does it mean to ignore the authority?
RB: [gives background on whiteboard]
... we started that the Origin was synthetic opaque with a UUID,
then ppl complained about the UUID so we got rid of it. So the
authority part could be used for other things, like crypto.
JS: the DOM should not reflect that authority?
RB: in future versions, we might make use of the authority part
TR: so my understanding is that, when the URI gets dereferenced, the
authority part gets ignored...
... the authority does not carry any semantics right now...
... the idea is just to keep it open for now, so we can do more with
it later
RB: Agreed
SL: might need to clarify that in section 4 of the spec
TR: need clarifications or it's going to be hard to parse
<tlr> 3986
RB: it still conforms to the URI specification, and the UUID would
still be dropped
<tlr> (thinking about this, I was wrong; ignore)
<tlr> (about the character repertoire, that is)
<lewontin> Maybe we want to drop the word "unique" in section 4
since we left open the possibility that multiple instances or
multiple widgets might share the same URI
<tlr> +1 to dropping "unique"
JS: I need to read the spec, will try to do that now
... have editorial comments
AB: if we look at the issues at the top of the doc. It seems we have
closed a few of those issues
RB: a lot of those are editorial
... so unicode, UUID are dropped. Can reference a bunch of things
from P&C. And the thing about dig sig, not sure what I meant.
JS and RB discuss some minor issues
AB: It's highly likely we are going to get some feedback once this
goes out. So, I'm inclined to push of a FPWD ASAP.
RB: I can have it ready this week
AB: the question is the, should we agree on a FPWD today?
RB: I think so
MC: I agree
AB: Robin will make the changes, so I propose to the group that we
get a resolution to publish
PROPOSED RESOLUTION: The group agrees to publish a FPWD once changes
agreed on during this discussion have been spec'd.
RB and BS discuss synthetic origins
<ArtB> BS: I would like to see a definition of synthetic added
<ArtB> RB: yes, I will add a definition
RB: a lot of people were uncomfortable with widget://
<tlr> tlr; think it's a bad idea to have a URI scheme which you
can't ever write out in absolute
<tlr> tlr: think it's fine to have authoring guideline that says
"relative uri references preferred"
<tlr> tlr: bu also think it's a bad idea to forbid them in the
implementation
BS: if I want to call a local resource, can I pass it a parameter?
RB: it should work, the javascript could access the relevant
document property and access that information
... you would not be able to post to a widget URI
JS: when I talked to TR, we agreed that POST would not work for 1.0,
but may be something that gets added later
BS: how does this work with HTTP?
RB: there is no relationship to HTTP, it's just a URI
TR: the only thing we define for the URI scheme is how to retrieve
files form a packaged, but nothing else. WRT queries, they are
ignored, but is reflected in the DOM... but we don't say that right
now, but it should say it in the spec
RB: fragments also
... ppl will be surprised if they are not there
TR: query is part of the resource identification
... fragment happens after the uri is dereferenced
RESOLUTIONS: The group agrees to publish a FPWD once changes agreed
on during this discussion have been spec'd.
<ArtB> Larry:
[34]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/06
42.html
[34] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0642.html
AB: before we close this topic, I did want to follow up on this
topic. Larry sent an email about thismessage
<ArtB> AB: the wiki
[35]http://www.w3.org/2008/webapps/wiki/WidgetURIScheme
[35] http://www.w3.org/2008/webapps/wiki/WidgetURIScheme
AB: at some point we were keeping track of all the candidates for
URI schemes
... in the wiki
RB: on first reading, it seemed very MIME constrained
JS: yes, I found the same thing.
JS reads the abstract
<timeless_mbp> [36]http://www.rfc-editor.org/rfc/rfc2557.txt
[36] http://www.rfc-editor.org/rfc/rfc2557.txt
<timeless_mbp> last paragraph, first sentence
<timeless_mbp> This document a) defines the use of a MIME
multipart/related
<timeless_mbp> structure
<timeless_mbp> -- if the abstract is accurate, then the RFC isn't
portable for us
RB: I think we need to deconstruct it and see what is good/bad in
there
<timeless_mbp> -- if the abstract is not accurate, then the RFC
isn't worth reading
<timeless_mbp> oh, *of first page
<scribe> ACTION: Send Larry a proper response about "thismessage"
and how it relates to Widget URI scheme
[37]http://www.rfc-editor.org/rfc/rfc2557.txt recorded in
[38]http://www.w3.org/2009/06/09-wam-minutes.html#action01]
[37] http://www.rfc-editor.org/rfc/rfc2557.txt
<trackbot> Sorry, couldn't find user - Send
<scribe> ACTION: Robin to send Larry a proper response about
"thismessage" and how it relates to Widget URI scheme
[39]http://www.rfc-editor.org/rfc/rfc2557.txt recorded in
[40]http://www.w3.org/2009/06/09-wam-minutes.html#action02]
[39] http://www.rfc-editor.org/rfc/rfc2557.txt
<trackbot> Created ACTION-353 - Send Larry a proper response about
"thismessage" and how it relates to Widget URI scheme
[41]http://www.rfc-editor.org/rfc/rfc2557.txt on Robin Berjon - due
2009-06-16].
[41] http://www.rfc-editor.org/rfc/rfc2557.txt
RB: from what I read it was _very_ MiME related
BS: what is the context of this discussion?
JS: the TAG is against creating new URI schemes unless one is REALLY
needed
AB: the history here is that we decided we needed a new URI scheme
for widgets, but we need to explore the whole landscape to make sure
nothing fits.
RB: I'm happy to discuss this with the TAG
... I love the TAG, I'm hoping I will be appointed to it.
<darobin> MC: I want to chair the AB
<Bryan> hello
<darobin> Scribe+ Robin
<ArtB> ScribeNick: darobin
P+C
AB: Jere, did we finish your comments?
JK: I think so yes, waiting on an email from MC for formal
acknowledgement
MC: will do that
JK: do we need that for the DoC? Do I need to say I'm happy?
MC: yes
JK: not trying to push MC
MC: need to make sure I've addressed everything
AB: from a process & scheduling perspective LC ends on 19/06, so no
specific rush
JK: happy to co-ordinate offline
AB: that's done
... anything heard from XML Core?
MC: no
<scribe> ACTION: Art to ping XML Core and the XML CG about reviewing
our PC LC [recorded in
[42]http://www.w3.org/2009/06/09-wam-minutes.html#action03]
AB: MWBP was also reviewing
<scribe> ACTION: Art to follow up with MWBP chairs for LC comments
[recorded in
[43]http://www.w3.org/2009/06/09-wam-minutes.html#action04]
AB: Marcin, you've sent several comments
... do you want to discuss them in the group
MH: I think we're handling it on the mailing list
... I'm not sure who else would speak up about versioning and
interoperability
AB: I wanted to talk about versioning
... what is the consensus about versioning for PC emails trail off
but that doesn't mean we have consensus and no issues
MC: I think we're fine
... we have made it as future-compatible as possible based on past
experience, on other groups' languages, on their recommendations
... we think our processing model is solid enough to handle the
future
RB: I agree
MH: I think on the mailing list we've agreed that versioning is
built on the NS, if there's incompatibility we can change it
... spec grows monotonically
... ensure back-compat of new releases
... two aspects: 1) the versioning of the format, 2) versioning of
the APIs
... e.g. Geolocation
MC: the P+C doesn't concern itself with the APIs
... but in P+C we take the same architectural approach
... future-compatibility without explicity versioning
... because you end up with a situation whereby you need to support
previous versions, it's heavy
... lots of legacy crap, like WAP, because there's content out there
that uses it
... we want to avoid that
MH: this changes my understanding
... you want to drop support for some APIs
MC: no, we just want to support one evolving API built to be
back-compatilble
MH: you assume there will be no deprecation
MC: yes
RB: and if there are breaking changes we change the name just like
for namespaces
Magnus: at some point you make changes, how do you determine whether
that something has changed without versioning?
MC: that approach doesn't work, it doesn't live up to the lifespan
that web content has
... "at least 100 years" is a design principle
... running the same Tetris a century from now
... archive.org should still run
... it's about creating a communication medium that will stay there
for a very very long time
... instead of dying after a few years
... pages from 1991 still work
MH: you don't know it's from 1991
MC: and you don't care which is the point
BS: that works as we have a slow transition from one language to
another but you expect applications to change faster
Josh: no on the web we expect things to keep working even if the
author is long dead
MC: like a dead
Andy: I don't expect Betamax to work today
Josh: as a user, if it has good content I want to watch
MC: that is a fault in the design of Betamax
... it's very frustrating
RB: and it's a loss to civilisation
BS: media conversion occurs all the time valuable content gets
converted
MC: we'll still support legacy stuff
BS: you mean if possible
MC: no, actually support
Benoit: a new browser created today would have to be compatible all
the way to 19991
MC: that's the point
BS: in the case of APIs you may find a better way to do it
RB: just change the name
BS: but then you don't have to support the old ones
RB: yes you do, there's content out there
MH: versioning helps
Josh, MC, Benoit, RB: no it doesn't
Benoit: versioning only works if you can decide to support just one
version
... or deprecate some versions
MH: it depends on the relationship between v1 and v2
Benoit: if v2 is very different from v1, it's not v2 it's
something different
BS: in principle I agree that back-compat is important
... but there will be cases when we leave technologies behind
... I think e.g. SMS will be replaced by SIP
MC: people will still want to access them
RB: and it's not a publishing format
BS: but I'm talking about an API
... there'll be a new API, but still the old SMS API
... what if the device doesn't have the capability?
Benoit: it's a capability issue
RB: that's a capability issue, not a versioning issue
MH: what if a browser doesn't implement all the APIs?
RB: then it's not very useful
AB: can we come back to the P+C spec
MC: the @version is only for authors, it only identifies the version
of the widget it's just a string that humans can interpret
MH: I wanted to change the name of this attribute
MC: it's in line with how it's used
MH: it's different from how it is in other W3C specifications
AB: let's try to get some closure
... does anybody object to the definition in the P+C?
MC: Marcin, what's your proposal?
MH: @widget-version
... I would like someone from the TAG to review this
... geolocation also define a version attribute on the object
... for the specification version
AB: I don't see a conflict between that and us
MC: I can't find that on the API
MH: it was discussed today, also with Anne
... if W3C is a spec vendor, then make it consistent
RB: that's already hopeless
<Zakim> MikeSmith, you wanted to comment
MS: the TAG is already having a discussion about versioning
... co-ordination is not a constraint
... you don't want W3C to attempt to impose coherence at that level
of granularity it would grind everything to a halt
AB: we're not going to find authority in the W3C that will tell us
what to do
MS: the one point in the process where that can happen is during
transition
... at that point a formal objection can raise to the Director
... and then the Director steps in, having collected information
from the TAG
AB: we don't want TimBL having to step in with the naming of an
attribute
Josh: I'm fine with a change to make the text say in its first
sentence that @version is the version of the widget, not of anything
else
<anne> fwiw, geolocation does not specify version on the object
<anne> it is being considered by some, but that's not the same
<anne> (and I don't think it'll happen)
MH: I think that by doing this we are breaking the architectural
assumption of W3C specifications
... elsewhere it is version of the specificaiton
... seen it in SVG, SML
thanks anne
MS: that's not true e.g. HTML
RB: note that those examples do not have the same semantics
Josh: we shouldn't blacklist a word because it didn't work in other
semantics we want to use it for useful semantics
MC: how can we clarify this?
JK: it's already clear, I don't see what the confusion is
Josh: agreed
... I was confused by the attribute type description can we stick
it after boolean, numeric (or alphabetically) so that it doesn't
jump out so much?
MC: yup
AB: third time, does anybody object to the way in which the @version
attribute has been defined?
[None]
RESOLUTION: @version as defined in P+C LC is acceptable
AB: any other issues to raise today?
MC: thank you Marcin for your feedback, fixed a lot of stuff
AB: +1
... is MaxF going to submit comments?
MC: no, Lachlan and Anne are
<ArtB> AB: this one
[44]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/07
89.html
[44] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0789.html
AB: one extra topic, Scott Wilson brought up a number of good
things, do we want to discuss some of them or is the on-list
discussion enough to make progress?
MC: I think we're fine for P+C a lot of his comments recently have
been about A+E
AB: I have a cloudy crystal ball
... modulo any major issues we should be ready to go to CR
... what's your sense here Marcos?
MC: it's hard to judge, the commenters I have lined up may bring up
issues
... I think people on the WG have gone through it, hopefully we've
weeded out issues
... I plan to finish before I go on holiday (18th)
AB: Dan, will MWBP review?
DKA: hasn't MWBP come back?
AB: for LC1
DKA: I don't think there'll be any feedback for LC2
<scribe> ACTION: Josh to go through P+C one more time [recorded in
[45]http://www.w3.org/2009/06/09-wam-minutes.html#action05]
AB: I don't want to get a bunch of comments on the 20th let's not
extend the time, it's been in LC since the beginning of the year
<DKA> +1
RB: should we ask the SVG WG to review?
Josh: good idea
<scribe> ACTION: Robin to ask the SVG WG to review (before the 19th)
[recorded in
[46]http://www.w3.org/2009/06/09-wam-minutes.html#action06]
<shepazu> noted
Benoit: what does vacation mean for the CR timing?
MC: probably July 1st
Benoit: can't decide on the 18th
MC: back on the 25th
... I should be able to ring in for the conf
AB: we could record a decision to go forward on the 20th
... using a call for consensus
... if there are no objections, I'll then send a transition request
DKA: we could do it on the 25th's call
AB: ok, let's do that
RB: I can fix the spec for pubrules if needed in MC's absence
MC: and it should be set to go anyway
AB: we'll cover testing tomoroow
... PC, AOB?
Josh: exit criteria?
MS: what's the plan?
MC: I like the XBL2 criteria
AB: I like the DigSig
MC: it says the same thing, but wishy-washy
Josh: I like the second sentence about openness
AB: not sure it's clear enough
MS: we don't need to overanalyse it, it's just about not getting the
spec out based on some in-house implementation that can't be
verified
... needs some degree of distribution and general testing
Josh: the DigSig one requires 2 implementations of each test not
of the whole thing. Let's use the XBL2 version
AB: if the implementation ships as part of a phone, does it count
DKA: yes
RB: yes
... we don't need to overlegalise it, this very same WG will decide
when we agree to move out of CR
... this really is process wonking
AB: can we not have the same EC for each spec
RB: how about reusing DigSig, but changing two implementations of
*each* test but two of *all* tests?
... it's a two word change
[AB summarises the proposal for MC]
<timeless_mbp> ... and demonstrated, according to the test suite,
two interoperable implementations.
Dave: we could even drop "each test"
AB: anybody object to replacing " for each test" with nothing?
MC: the XBL2 one is better but I can live with it
... I have made the change
RESOLUTION: the agreed-upon DigSig CR EC will be applied to P+C and
to all subsequent specs in this WG
Updates
DKA: do we have a PAG call?
MS: yes
AB: the PAG is having weekly conferences as per process
Discussing Brians input
BS: it had to do generally with the purpose for the access element v
the feature element
... there were two things I proposed
... 1) a @required flag
... you get only what you declare in the way it is defined, which
means that without prior knowledge that a specific domain is going
to be allowed, you won't find out until it doesn't work
... you can't get access to things that may be useful but not
essential
... <feature> was designed around that, but not <access> which I
find is similar in nature
... you could have alternate approaches if a netres is not available
... I based access@required on the feature
RB: it's commented out, pushed out to v2
BS: why defer?
AB: I think the general reason why some of us felt we should put it
off is because we hit LC around christmas last year, and we'd like
to consider ourselves feature-complete
<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)
BS: but WARP has been moved out into a separate spec
<MikeSmith> trackbot, associate this channel with #webapps
<trackbot> Associating this channel with #webapps...
BS: is it assumed WARP is near LC?
<MikeSmith> trackbot, bye
<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)
AB: when we made that decision, it was still in PC
... so does the decision move with it?
<MikeSmith> trackbot, associate this channel with #webapps
<trackbot> Associating this channel with #webapps...
<MikeSmith> trackbot, status
<trackbot> This channel is not configured
<MikeSmith> trackbot, status?
<trackbot> This channel is not configured
AB: the idea was that WARP should move at warp speed
... I suggest that the same rationale applies
... we don't want any new features
MC: I still don't see much use for these attributes, so from Opera's
point of view we don't see them as that useful
JK: I'm indifferent about @required, but @duration is disconcerting
... I see a lot of echo of J2ME and the result of that is when these
values were used and applied to mutiple different APIs it very
quickly turns into excessive prompting
<MikeSmith> trackbot, init
<MikeSmith> trackbot, status
<trackbot> This channel is not configured
JK: that's a UX killer if we bring that into <access> where the
granularity is a URL, and you have several of these, you're going to
get more prompting, and a dreadful UX
<MikeSmith> trackbot. leave
<MikeSmith> trackbot, leave
RT: I agree, you're implying UX with prompting we don't want to
imply UX, that's an implementation thing
MH: consolidation of the prompts?
<MikeSmith> trackbot, associate this channel with webapps
<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)
<MikeSmith> trackbot, associate this channel with webapps
<trackbot> Associating this channel with webapps...
<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)
<MikeSmith> trackbot, associate this channel with #webapps
<trackbot> Associating this channel with #webapps...
MH: this is an important factor
BS: the purpose is not to mandate a UI/UX
... obviously apps have to be designed or vetted to access some
features
<MikeSmith> trackbot, status?
<trackbot> This channel is not configured
<ArtB> Bryan's email:
[47]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/at
t-0844/00-part
[47] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/att-0844/00-part
BS: the purpose of this disclosure is not to promote a given
security model
<MikeSmith> trackbot, status?
<trackbot> This channel is not configured
<MikeSmith> trackbot, leave
BS: we will eventually have a process of alignement
<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)
<MikeSmith> trackbot, associate this channel with #webapps
<trackbot> Associating this channel with #webapps...
BS: we see this process of prompting as essential
<MikeSmith> trackbot, status?
<trackbot> This channel is not configured
BS: but this is just like feature@required
... this is about what the widget needs to be able to do
MC: even if @required is going to be useless because the URL might
be unavailable
BS: but you can still have a policy
MC: yeah, but I think it's overkill
... <access> says what you want to access, and then it might but
unavailable
... so you're already handling that case
BS: but the widget won't install
RB: we don't say whether the widget gets installed or not
MC: you know access@uri
... if it's not allowed to access something inside the range of
URIs, the required doesn't change anything there
... on feature it's different but I could live with dropping it
there
<MikeSmith> action-1
errrrr
<scribe> ACTION: RB to send Larry a proper response about
"thismessage" and how it relates to Widget URI scheme
[48]http://www.rfc-editor.org/rfc/rfc2557.txt recorded in
[49]http://www.w3.org/2009/06/09-wam-minutes.html#action07]
[48] http://www.rfc-editor.org/rfc/rfc2557.txt
<trackbot> Created ACTION-354 - Send Larry a proper response about
"thismessage" and how it relates to Widget URI scheme
[50]http://www.rfc-editor.org/rfc/rfc2557.txt on Robin Berjon - due
2009-06-16].
[50] http://www.rfc-editor.org/rfc/rfc2557.txt
sorry, had to undrop it
MC: the request would just fail
BS: but with @reuiqred you can check that by policy
... you could implement APIs on the web represented as URIs much
more flexibly, but they should be equal citizen with feature
MC: required on feature is a legacy from when we had fallback this
has gone so it could go too
RB: if we drop @required on feature we have to go back to LC
BS: if you discover incompatibility earlier, you have a better UX
Josh: wrong, users get pissed because they can't install the widget
that their friend has
... if it bails out too early I can't use it
... I can show examples of this
BS: I would prefer to not even offer that to download based on
capability
... we can do this in PC, or we can do this externally
MC: why do we assume that there will be different policies for
different devices
BS: we do policy per context, in MIDP and native
MC: which are very unsuccessful
<dom> trackbot, associate this channel with #webapps
<trackbot> Associating this channel with #webapps...
BS: some people chage, some people don't
AB: the more we talk about policy, the more I think it's a DAP
problem
RB: thank you Art, you'll pay for that
<JereK> +1
<dom> trackbot, status?
<trackbot> This channel is not configured
<dom> ACTION-1?
<trackbot> ACTION-1 -- Doug Schepers to find All Open Issues For
DOM3 Events and Update the Specification -- due 2009-03-18 -- OPEN
<trackbot> [51]http://www.w3.org/2008/webapps/track/actions/1
[51] http://www.w3.org/2008/webapps/track/actions/1
AB: I'm not hearing a lot of support within this WG to do it here
... there's an opportunity to submit furhter comments when FPWD is
out
... WARP isn't in LC, so in theory it's open to features
emphasis on theory
AB: I recommend ending the discussion now, and discussing when the
FPWD is out
MC: in the future, there's only ever going to be one policy
... for all devices
RB: developers certainly would prefer that
RESOLUTION: Policy gets discussed in DAP
MC: we can add it in a separate spec
BS: we'd like to avoid the overhead of addiotinal spec
Josh: we'd like to avoid the overhead of extra attributes that turn
out to be useless
the WG opens a bet about the future
ADJOURNED
Summary of Action Items
[NEW] ACTION: Art to follow up with MWBP chairs for LC comments
[recorded in
[52]http://www.w3.org/2009/06/09-wam-minutes.html#action04]
[NEW] ACTION: Art to ping XML Core and the XML CG about reviewing
our PC LC [recorded in
[53]http://www.w3.org/2009/06/09-wam-minutes.html#action03]
[NEW] ACTION: Josh to go through P+C one more time [recorded in
[54]http://www.w3.org/2009/06/09-wam-minutes.html#action05]
[NEW] ACTION: RB to send Larry a proper response about "thismessage"
and how it relates to Widget URI scheme
[55]http://www.rfc-editor.org/rfc/rfc2557.txt recorded in
[56]http://www.w3.org/2009/06/09-wam-minutes.html#action07]
[NEW] ACTION: Robin to ask the SVG WG to review (before the 19th)
[recorded in
[57]http://www.w3.org/2009/06/09-wam-minutes.html#action06]
[NEW] ACTION: Robin to send Larry a proper response about
"thismessage" and how it relates to Widget URI scheme
[58]http://www.rfc-editor.org/rfc/rfc2557.txt recorded in
[59]http://www.w3.org/2009/06/09-wam-minutes.html#action02]
[NEW] ACTION: Send Larry a proper response about "thismessage" and
how it relates to Widget URI scheme
[60]http://www.rfc-editor.org/rfc/rfc2557.txt recorded in
[61]http://www.w3.org/2009/06/09-wam-minutes.html#action01]
[55] http://www.rfc-editor.org/rfc/rfc2557.txt
[58] http://www.rfc-editor.org/rfc/rfc2557.txt
[60] http://www.rfc-editor.org/rfc/rfc2557.txt
[End of minutes]
Received on Friday, 12 June 2009 10:43:50 UTC