- 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