- From: Scott Wilson <scott.bradley.wilson@gmail.com>
- Date: Fri, 12 Jun 2009 12:54:03 +0100
- To: public-webapps <public-webapps@w3.org>
- Message-Id: <1604551D-3E23-4517-A53B-1DBCF11F39FD@gmail.com>
One scenario for hasFeature(): 1. I install a Widget with: <feature name="http://my.feature.com/x" required="false"/> 2. In my Widget's JavaScript, I have something like: if (hasFeature("http://my.feature.com/x")){ doCoolThing(); // great, we have the X API! Lets use it } else { doLessCoolThing(); // ok do something that doesn't need the X API } How can this be realised if hasFeature() is removed? Or should this UC be specifically out of scope for A&E? For example, would I have to create two different widgets, one with X and one without? Without hasFeature(), what does P&C <feature ... required="false"> mean? S However, the Widget can't do On 12 Jun 2009, at 11:45, Arthur Barstow wrote: > The draft minutes from the June 10 Widgets f2f are available at the > following and copied below: > > <http://www.w3.org/2009/06/10-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/ > > - DRAFT - > > Widgets F2F Meeting > > 10 Jun 2009 > > [2]Agenda > > [2] http://www.w3.org/2008/webapps/wiki/WidgetsLondonJune2009 > > See also: [3]IRC log > > [3] http://www.w3.org/2009/06/10-wam-irc > > Attendees > > Present > Benoit, Mike, Josh, Jere, Robin, AndyB, Marcos, DanA, David, > Laura, Marcin, Magnus, Kai > > Regrets > Chair > Art > > Scribe > Art > > Contents > > * [4]Topics > 1. [5]A+E spec > 2. [6]A+E spec - again ... > 3. [7]Window Modes / Query spec > 4. [8]Testing > * [9]Summary of Action Items > _________________________________________________________ > > > > <ArtB> ScribeNick: ArtB > > <scribe> Scribe: Art > > Date: 10 June 2009 > > <MikeSmith> trackbot, status? > > <trackbot> This channel is not configured > > trackbot, associate this channel with #webapps > > <trackbot> Associating this channel with #webapps... > > <MikeSmith> trackbot, status? > > <trackbot> This channel is not configured > > <MikeSmith> ArtB: trackbut is confused > > Scribe+ David > > A+E spec > > <scribe> ScribeNick: drogersuk > > AB: Agenda is API and Events > ... we have several red block issues > ... and there is a discussion related to storage > > <Marcos> [10]http://dev.w3.org/2006/waf/widgets-api/ > > [10] http://dev.w3.org/2006/waf/widgets-api/ > > MC: To progress this, viewMode is not a big issue here > > AB: Let's go back to the start of the document. Is the abstract > up-to-date? > ... The title includes events but there aren't a whole lot of events > > MC: There are events > > JS: 3rd bullet point in abstract doesn't make sense > > MH pointed out some editorial issues in the abstract > > scribe: defined by... defines for example > > JS: requests in the 4th bullet should be request > > AB: What is the interface that supports the last bullet? > hasFeature()? > > MC: Yes > ... Perhaps we should concentrate on some of these issues rather > than the editorial points > > AB: Are there any definitions we are missing? > ... In section 4 > ... we've talked about nailing down origin > > MC: it isn't really relevant in this spec, because origin pertains > to the storage interface and that already defines where you get > origin from > > AB: So we can have this discussion when we discuss the storage > attribute > > MC: As long as we have consensus in the group that each widget has > its own storage and that storage cannot be accessed by other > widgets.. > > AB: We'll deal with this as we get to it in the document > ... Section 5 begins with the block of the widget interface... > > JK: We need to define what is a feature etc. > > MC: Do we need a more technical definition than P&C? > > There was a discussion about how to define feature > > <darobin> [11]http://www.w3.org/TR/SVG11/struct.html#SwitchElement > > [11] http://www.w3.org/TR/SVG11/struct.html#SwitchElement > > <darobin> actually, this better: > [12]http://www.w3.org/TR/SVGMobile12/struct.html#SwitchElement > > [12] http://www.w3.org/TR/SVGMobile12/struct.html#SwitchElement > > <drogers> AB: Back to section 4 - let's look at the first red block > > <timeless_mbp> We considered offering a video decoder as another > example of a "feature" in addition to an API. While we decided not > to list it as an example, this isn't because it isn't an example, > but merely because we decided not to list a second. > > <drogers> MC: The first red block item covers some items that are > not defined - e.g. viewMode > > <drogers> ...viewMode should be in the window modes spec which is > not written > > <drogers> AB: Robin agreed to be the editor of this > > <drogers> ...obviously Robin has had higher priorities > > <drogers> AB: mediaquery and windowmodes were going to be two specs > > <drogers> MC: and I think they should be one > > <drogers> AB: We don't want a dependency on the CSS working group > > <drogers> MH: This is a question of timeline > > <drogers> AB: So what is the consensus? > > <drogers> It was agreed that there would be one spec for this > > <drogers> RESOLUTION: There will be one specification for > windowmodes and mediaquery > > <drogers> MC: We need to align the attributes with the steps to > remove the next red block > > <drogers> 5.1 - viewMode attribute: > > <drogers> in mediaquery spec - feature is defined too > > <drogers> ...we need an explanatory note here > > <drogers> MC: The text does not make sense > > <drogers> <drogers writes z version on whiteboard> > > <drogers> MC: The user agent makes the decision about the window > mode display > > <drogers> ...it is described in the P&C spec (lifecycle) and also in > the windowmodes spec > > <drogers> AB: The sentence: "Upon instantiation...." was removed# > > <drogers> The red block issue: this is a computed value was edited > to change to editorial note. It is to be dealt with by the Editor > > <drogers> Locale attribute was discussed > > <drogers> MC: I don't think this has relevance anymore > > <drogers> BS: This could be useful > > <drogers> JS: You would want the widget to see everything though > > <drogers> ..this definition is currently wrong and unhelpful > > <drogers> MC: We will return the user agent locales > > <abraun> Noting for drogersuk > > <abraun> MH: Why is it identifier and not id > > <abraun> MC: Because of potential confusion around XML id > > <abraun> RB: ok to move identifier to id because their will not be > confusion with XML id > > <abraun> MC: ok > > <abraun> MC: will change width and height to postive numbers. > > <abraun> AB: good change > > <abraun> MH: authorInfo why not author.info > > <abraun> abraun: Josh: each dot adds a lot of overhead. > > <abraun> BS: why not just author > > <abraun> MC: ok > > <abraun> dicussion leads to question Do we need to define > installation vs instantiation in P&C? > > <abraun> more discussion.... > > <abraun> AB and Josh prefer definition in A&E > > <abraun> MC disagrees > > <darobin> > [13]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/04 > 45.html > > [13] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0445.html > > <abraun> AB: where less important than that it is done and is > consistent > > <abraun> general concern about scope creep delaying P&C > > <abraun> ACTION: Marcos to define installation and instantiation > [recorded in > [14]http://www.w3.org/2009/06/10-wam-minutes.html#action01] > > <trackbot> Created ACTION-355 - Define installation and > instantiation [on Marcos Caceres - due 2009-06-17]. > > <abraun> AB: wonders if other w3c spec define these > > <abraun> MH: may have something in BONDI lifecycle document > > <abraun> ACTION: Mhanclik to investigate definitions of installation > instantiation in BONDI work [recorded in > [15]http://www.w3.org/2009/06/10-wam-minutes.html#action02] > > <trackbot> Created ACTION-356 - Investigate definitions of > installation instantiation in BONDI work [on Marcin Hanclik - due > 2009-06-17]. > > <ArtB> ScribeNick: abraun > > <scribe> continued discussion on installation vs instantiation > > <Marcos> Installation means the first time a widget package and the > configuration document have successfully passed through the steps > for processing a widget package. > > <Marcos> Instantiation is any subsequent run through the steps for > processing a widget package post installation of a widget. > > MC: when you install you set preferences. > > AB: why is install only first time > > BS: I took installation means creating something new rather than > restarting the first time > > <hendry> postinst and package life cycle is kinda defined by debian. > e.g. 'postinst' in > [16]http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html > > [16] http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html > > MC: intialization is the first time for setting prefs etc > > Josh: yes, then intiatiation is for making multiple copies > > <timeless_mbp> s/int/init/ ? > > <timeless_mbp> err no... someone else fix that line in the minutes > :) > > timeless fix the line? > > <timeless_mbp> intiatiation => initiation ? > > <timeless_mbp> intialization => initialization > > AB: group has agreed to change instantiation to initialization > > <richt> have we lost zakim or this is deliberate? > > <timeless_mbp> zakim said it wasn't needed and left > > <timeless_mbp> MikeSmith: any idea if this was a time expired thing? > > working through the spec to investigate individual instances of > instantiation > > MH: how do instantiate a file > ... has issues with authorHref name > > Josh: Link is better than Href > > AB: should have compelling reasons for change this late in the game > > MC: won' change P&C because it is substantive > > agreed that authorHref will remail as is in A&E > > AB: authorEmail will also remain as is > > BS: is 5.8 description limited in content? can it have markup? > > MC: yes but will be stripped out as defined in P&C > > BS: so I can put a URI in description? > > Minutes reFlect no additional comments on 5.10 5.11 > > <ArtB> Scribe+ Jere > > <ArtB> ScribeNick: JereK > > A+E spec - again ... > > AB: A&E, preferences. Lots of discussion in the past, strong > feelings. > ... related to HTML5 storage. Red block. > ... Arve has commented about this. Marcos, lead us. > > MC: Red block added by me based on input by Hixie. Need to define > error conditions when setItem called for read-only > ... In context where you already have storage, must not end up with > two. > > JS: Let's look at section 3.4. > > MC: It's not there anymore, in separate spec now. > > BS: Diving into storage now? > > <ArtB> Web Storage spec: [17]http://dev.w3.org/html5/webstorage/ > > [17] http://dev.w3.org/html5/webstorage/ > > JS: No, but how you reference it. > > <Marcos> [18]http://dev.w3.org/html5/webstorage/ > > [18] http://dev.w3.org/html5/webstorage/ > > BS: Either local or remote storage? > > JS: Just about the binding. > ... Want to have something like in HTML5. > > BS: Clone this section from HTML5? > > JS: Yes > > BS: So not reference? By cloning this section into A&E, not going to > reference? > > JS: No, still going to reference. > > AB: Josh, what parts? > > JS: Not the 3rd para, or at least very different. Take first two > sentences, refer to widget. > ... must have a set of preferences for each instance. > ... fourth thing not needed. > > Noted that Marcos should do this as Josh describes in detail. > > JS: Do people want to listen to preferences change events? > ... some version of para #6 is maybe needed. > > (Marcos proceeds to read the para/sentence.) > > MC: Yes, we expect that. > > MH: Do I need to read HTML5 to understand A&E? > > MC: Have to solve mutex problems anyway. > > JS: Do we have workers? > > MC: Yes. > > AB: Impl. detail? > > JS: Workers preempt mutexes? > > MC: Significant amount of work required. > ... not super-difficult, though. > > AB: What will you have to copy? > > MC: Preferences and read-onlyness... > > MH: Could be done consistently in DAP; similar stuff defined in > BONDI now. > > RB: Storage already defines exception codes. > ... would use the same set of codes. > > MC: super simple hash map > ... only defines quota error and index size error > > AB: Important to nail this down, identify the parts. > ... almost like defining a profile of Storage. > > JS: removeItem also has to be able to throw read only error. > ... in addition to setItem. > > <Marcos> If setItem() or removeItem() is invoked with a value > defined as read-only, then the user agent must throw a > NO_MODIFICATION_ALLOWED_ERR exception. > > (live editing of relevant text parts) > > BS2: First ever instantiation? > > (Discussion about installation - instantiation comes up again... > waiting for the outcome) > > MC: Not yet satisfied, but might leave that as impl detail. > > JS: Can we have an "unConfigured" widget instance? > > AB: People can still submit comments if we go with what we now have. > ... All relevant parts copied from WebStorage now? > > MC: Yes > > AB: Any other comments? (No.) Moving on to 5.13. > ... No feedback. Moving on to 5.14 (hasFeature method). > > MC: Do we need this? > ... no means of requesting a feature. > > JS: Cheaper for impl, easier on the user to just use it and deal > with any errors. > > MH: Not returning objects anymore. You request a feature and set up > a callback. > ... not in global namespace. > > JS: hasFeature needs to die. > > MH: Similar discussion on geolocation list. > > AB: Anybody object to deleting 5.14? > > BS: Didn't see that coming. > > AB: Marcos, is this harmful? > > MC: No, just useless. > > AB: Some people find it useful. Anyone else object? > > BS2: How can a developer, in a generic sense, find out if something > is available? > > JS: You check for objects, and use them if they are available. > ... Object needs to be defined. > > MC: Scott Wilson's e-mails re: "What does it mean to have an > unavailable API?" > > <ArtB> ... > [19]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/07 > 12.html > > [19] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0712.html > > MH: hasFeature is about access to config.xml > ... if something is required and it's not there, the widget is not > instantiated > > MC: Does not tell you everything > > JS: You always only get information you already know from > hasFeature. > > AB: If we do keep it, red block issue remains. > > MC: Deleted the red block. > > JS: Need to add that the URI needs to be an exact match. > > MC: No point in adding if we kill it. > > AB: Could explicitly identify it as a feature at risk. > > MC: requestFeature as described before could work, but seems like a > mobile optimization > > MH: Same thing could happen on desktop. > > MC: Should be discussed in DAP. > > JS: +1 to MC > > MC: Better bound to the window object. > > MH: Affects security. > > JS: widget isPropertyOf window > > MH: About window.widget.hasFeature or window.hasFeature? > ... would drop hasFeature and deal with requestFeature later > > AB: When Bryan comes back we'll have a formal vote and a decision. > ... On to 5.15, openURL > > <Bryan> be there in a minute > > JS: Need someone to have a veto > > AB: any objections to 5.15? > > MC: It is a SHOULD > > JS: And failure case is a MUST > > MC: adds statement about UA rejecting > > JS: can live with it > > AB: any additions to modfications? > ... none, accepted. > ... Back to question about deleting 5.14 > > BS: Some other means to do the same thing? > > AB: Yes, as DAP gets going they'll look at both {has/request}Feature > use cases. > > RESOLUTION: hasFeature() will be removed from A&E > > AB: Just two more pieces to go with A&E > > BS: About openURL, assumption about response? > > JS: No feedback, worth noting? > > BS: Not returning any data? > > JS: Yes, it's void. > > BS: Only argument is URI, no limitations? > > MC: Yes, openly defined. > > AB: On to 5.16, getAttention() (basically a prompt) > ... Any objections to the current text? > ... None noted. > ... On to 5.17, showNotification() > > BS: Is string just plain text? > > JS: 3rd argument applies it is not modal > ... text is subOptimal > > AB: If UA posted this with title, would there be something to click > to make it go away? > > JS: Yes, but widget won't know when it happened. > > BS2: iPhone notification example > > (discussion of how the iPhone applications notify the user) > > AB: Kai, how would you test user ack? > > MH: WebIDL for this has issues > > MC: Should get rid of this, to specify elsewhere to get a more > complete notification model > > AB: +1 to MC. Any other approaches? > > JS: Feature at risk would be a good baseline > > AB: Strong feelings about the options? > > MC: Have to talk to Arve > > AB: MC will mark it as at risk of being removed. > > JS: Draws analogy to Growl notifications > > MH: Security workshop Dec 2008: Mozilla and async prompts. Is > showNotification part of this effort? > > JS: If doing that, there is overlap. Sync notifications eat up > stack. > ... If Windows would have that, it would be duplicated. > > AB: Want to close discussion about A&E > > MC: References already done. > > AB: OK to remove red block then? > > MC: Yes. > > AB: Publication plan of A&E? > > MC: Needs a day of TLC > > AB: Is the next pub a WD or LC? > ... Any objections for the next version being a LC? > ... None recorded > ... When do we record a resolution that it is ready for LC? > ... Propose to publish LCWD with Marcos' changes, ASAP > ... Earliest pub date most likely June 18th, needs to be ready by > June 16th > > <anne> [20]http://www.w3.org/TR/widgets/ is going to LC again? > > [20] http://www.w3.org/TR/widgets/ > > MC: Want to finish P&C first, comments from Marcin > > <Marcos> anne, no > > AB: Agree to publish LC on June 18th? > ... No objections recorded > > RESOLUTION: Agreed to public LCWD of A&E as soon as it is ready. > > Time for a break, testing with Kai Hendry next. > > <anne> Marcos, cheers, getting confused by all the abbreviations > > For the record, "A&E" is Widgets 1.0: APIs and Events > > <ArtB> Scribe+ Josh > > Window Modes / Query spec > > <ArtB> ScribeNick: timeless_mbp > > <ArtB> Window Modes: > [21]http://dev.w3.org/cvsweb/2006/waf/widgets-wm/ > > [21] http://dev.w3.org/cvsweb/2006/waf/widgets-wm/ > > [22]http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-wm/Overview > .src.html?rev=1.1&content-type=text/html;%20charset=iso-8859-1 > > [22] http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-wm/ > Overview.src.html?rev=1.1&content-type=text/html;%20charset=iso-8859-1 > > AB: Marcin has noted that we should do some work on this > > <hendry> in [23]http://hasather.net/widgets/widgets.rnc : > application, floating, fullscreen, mini, all > > [23] http://hasather.net/widgets/widgets.rnc > > AB: Brian, you agreed to provide some input > ... in the absence of any real inputs, then we'll just open the > floor for comments > ... when we're done with that, we'll talk about what's the next step > > JS: useless comment to marcos :) > > AB: this was cobbled together in Paris based on a rough consensus > > Kai: what are the view modes defined by this specification? > > Marcin: We had a discussion yesterday, what is discussed here is > window mode, like full screen > > MC: In the media query specification, they define different features > for media types > > RB: If we wanted to balance this, we could call these the "docked > media feature", ... > > AB: let me give a little bit of background; during the february > meeting, we realized that we wanted the packaging spec to proceed > and not be blocked on window modes > ... we agreed that P&C would have absolute minimal definitions and > the canonical list of values > ... and this spec would contain the fleshed out definitions > ... I believe this document is version 1.0 > ... what is here is what was entered in february and has no > attention since then > > Kai: Was what I wrote on irc the list? > > MC: yes > > BS: I'm trying to understand "media feature", I'm familiar w/ SIP, > but you're referring to CSS "media feature" > > <[24]http://www.w3.org/TR/css3-mediaqueries/> > > [24] http://www.w3.org/TR/css3-mediaqueries/%3E > > <www.w3.org/TR/css3-reader> > > <[25]https://developer.mozilla.org/En/CSS/Media_queries -> > > [25] https://developer.mozilla.org/En/CSS/Media_queries > > Kai: how do media modes relate to things like > application/floating/fullscreen? > > MC: these don't line up because the spec is out of date > ... we intend to update it to align with P&C > > BS: is this intended to address audible media modes? > > MC: yes ... > ... e.g. @media aural and (widget-mode: docked) { .... } > > AB: the things after @media <here> are defined by CSS3 > ... what we're saying is that the author can further qualify @media > modes with widget-modes to affect how things are rendered > > MC: I don't think you can change the @media > > BS: what about changing from minimized to maximized > > RB: those are widget-mode, not @media > > BS: oh, i'm confusing those two things, because the two specs > interact > > RB: the examples shouldn't be there, there should be more text, > there should be examples with details in the rules > > BS: So I can test things with this? > > MC: You could use A&E to do that instead > ... Except media type changed event would tell you about some things > here > > Benoit: we put in ResolutionEvent in Paris because it needed to be > somewhere > ... and if someone complains *and* provides it where it belongs, > we'll gladly remove it > > JS: There are two modes here > ... The media types will be unlikely to change for the life span of > an instance on a device > ... And widget modes which the widget will be able to ask the user > agent to change > ... What this spec allows is for the widget to use CSS to control > how the widget is presented according to the intersection of these > two criteria > > BS: The combination of the media type and the widget mode allow the > widget to style its presentation in that combination. And that's the > purpose of this spec? > > Benoit: exactly > > BS: And the other thing is some event stuff, which should be > elsewhere? > > Benoit: yes > ... The general issue is that in the P&C spec, there was a need to > define modes > ... This spec is to enable the P&C spec not to have that stuff, > because it was too much information > > BS: do we expect of have more features here? > ... the feature to me is an example of a widget mode. Widget, > Docked, Full Screen > ... Application > ... In Widget mode, you get a box? > > Benoit: Not even a box, just a space > > BS: Will there be more? > > Benoit: I believe that set was defined > > AB: Let me find the reference > > Benoit: this was discussed > > BS: what about icons? > > Benoit: there were reasons icons were taken out > > BS: this set of modes is presumed to be complete? > > AB: Yes. > > MO: Icons. Was that related to notifications? > > AB: I wouldn't say it was never covered. We talked about icons being > one of the states > > JS: The reason we don't have icons in the list is because icons > coexist with another state > > AB: P&C has 5 values, what's the definition of mini? > > RB: it's not very well specified > > MC: It's a mode that's smaller than full screen > > Benoit: originally this comes from Vista where you have docked and > undocked > > MC: You have full screen... > ... Application, which is slightly smaller with some chrome > ... Floating, which is application with no chrome > ... Mini, which is UA specific > > RB: Art, maybe you can iTunes to show Mini player > > (Art shows iTunes in Mini mode, and RT pokes fun at RB) > > MC: it's up to the implementation to say which mode it's putting > things in > > RB: it would be nice to have semantics to the keywords > > BS: What about all? > > RB: all is useful for having a rule that applies to all modes > > BS: Can I query for mode all? > > Benoit: No > > RB: But if you queried to see if it matched all, it'd say yes > > Marcin: We have widgetMode, viewPort and widget-mode > > AB: We recognize that this draft is out of date/sync > > Marcin: the question is do we need this document > ... currently what's needed in terms of modes is already listed > outside this specification > ... A&E offers an api to get/set modes > > <hendry> Marcos: floating in terms of X means a window that isn't > tiled (~docked) or fullscreen. It has no relation to chrome. /me > worried there might be confusion. > > Marcin: for me it seems like media query is an informational > document > ... but what about all? > > RB: I don't think all will be exposed > > Benoit: All is for CSS > > <MagnusO> Howis ALL related to Fullscreen? > > Marcin: Could we add a note that 'all' will never be returned by A&E > viewMode? > > (MC points to the P&C spec with some section highlighted) > > (including "all") > > Marcin: The issue is that we're using the same token list for 3 > places > ... but in one place it doesn't fit (A&E) > > <MagnusO> So ALL is really same as able to appear in any form, full, > mini etc. > > MC: What I am getting is that i need to clarify where/when all is ok > > Benoit: All should be listed in its own sentence > > RB: yes, outside the original list, with an explanation. > > AB: The default is floating > > MC: In addition, the all keyword can be used to denote that all the > valid view modes are supported by the widget > > JS: +1 > > (offtopic chatter) > > Marcin: P&C talks about a widget views spec > ... and widgets views spec is really green -- not yet defined > ... and we can take P&C to a certain state > > AB: It isn't undefined, it's underdefined > ... Again, we ask that if people have inputs for window modes/views, > we ask for inputs > > Marcin: and we're asking for input as quickly as possible > > MC: We intend to publish a first working draft (FWD) the first week > of July > > BS: The height and width attribute in P&C have a reference to the > widget views spec > > AB: We need to make sure Widgets VIews talks about which modes would > support this > ... Some of us feel that User Agents should have flexibility wrt > what modes might support this stuff > > BS: This should be easy, right? > ... Which attributes are dependent on view modes, and which are > independent. and could we have a table? > > AB: That sounds great for someone to write > > <scribe> ACTION: Bryan to make a table (if it's easy) [recorded in > [26]http://www.w3.org/2009/06/10-wam-minutes.html#action03] > > <trackbot> Created ACTION-357 - Make a table (if it's easy) [on > Bryan Sullivan - due 2009-06-17]. > > Testing > > Kai: Widget testing. My name is Kai Hendry. I work for Aplix > Corporation. > ... I spend one day a week on the Mobile Web Testing group, which a > w3 wg > ... Have you heard of the Mobile Web Compatibility Test for Mobile > Browsers? > > (many hands raise) > > scribe: Widget Tests!. So I started months ago > ... Marcos told me that some things were stable, so I started > working. > > <DKA> Web Compatibility Test for Mobile Browsers: > [27]http://www.w3.org/2008/06/mobile-test/doc.html > > [27] http://www.w3.org/2008/06/mobile-test/doc.html > > scribe: I wrote a blog about these tests > > <DKA> I am a big fan. > > scribe: I wrote a bunch of zip files for testing > > <hendry> [28]http://wtf.webvm.net/ > > [28] http://wtf.webvm.net/ > > scribe: That's the next thing I've been doing, with a guy named > Robert from Opera > > [29]http://dabase.com/ > > [29] http://dabase.com/ > > [30]http://dabase.com/blog/Widget_Test_Framework/ > > [30] http://dabase.com/blog/Widget_Test_Framework/ > > Kai: The idea with WTF is you point your Widget Runtime.... > ... there is a test harness > ... did you want to write some tests? i could show you how this > works :) > ... A lot of the tests are automated in that you have a config.xml > and the widget would load, and you would query it with the widget > API to see if the widget would load > ... You would load the widget, test a property and see if it's > correct and post a result > ... To get more done, it would be good if the spec was stable > ... If you want to help out, you could provide some tests > ... Or if you wanted me to add something, you could email me > > Benoit: do you have any target objectives? > > Kai: not really. I tried to pin it to when the spec was going to be > stable, but that stopped being realistic > ... It's been a learning experience > ... At first I wrote things by hand > > <DKA> hand > > Kai: I learned from Opera to use JS to generate tests > > MC: I think we will contribute stuff > > Kai: The [Opera] Spartan stuff is really cool, because it can do > stuff with (green/red) colors on the screen > > AB: I have some questions > ... Kai, at one point in time you were maintaining this CVS > repository > > Kai: I use git and dump to Dom, and he pushes to CVS > > <scribe> ACTION: Art to coordinate with Kai and Dom [recorded in > [31]http://www.w3.org/2009/06/10-wam-minutes.html#action04] > > <trackbot> Created ACTION-358 - Coordinate with Kai and Dom [on > Arthur Barstow - due 2009-06-17]. > > AB: The LC period for P&C ends June 19 > ... Assuming we don't get any major issues in the next 9 or 10 days, > and we should enter Candidate by the end of the month > ... In order to begin the Candidate phase is to define how we get > out of Candidate phase by declaring a call for implementations > ... which involves us defining a complete test suite > > MC: how do we judge if the changes we've made to the spec are > substantive enough to prevent us from doing CR v. LC? > > MS: The WG decides > > <anne> (Actually, per the Process document you'd have to go back to > WD even, not another LC, as I understand things.) > > <anne> (And it's a MUST requirement too. Substantive change is > defined here: > [32]http://www.w3.org/2005/10/Process-20051014/tr.html#substantive-c > hange ) > > [32] http://www.w3.org/2005/10/Process-20051014/tr.html#substantive-change > > AB: What he says is true > ... that assumes we've had a substantial comment > > <anne> (Actually, Marcos already made a substantive change...) > > Benoit: We've already raised this question > > MC: He's made the assertion that we've made substantive changes > > DA: I'm saying that what constitutes substantive changes is up to > the Chair > > RB: A good definition of a substantive changes is something which > would cause an existing implementation to cease to be conformant > > <tlr> the important point when going to CR is "does the change > invalidate previous review" > > <anne> it's all defined in the above link > > MC: There are a bunch of changes, including an l10n change yesterday > > <anne> new rules for case sensitivity of folders certainly would > affect any implementation > > AB: We can as long as we the working group by consensus determine > that the changes are substantive > > RB: What we have to do is list the changes in the transition request > ... and then it's up to the director to decide > > MS: Ultimately, that's what it comes down to, and that's where it > would be arbitrated > > Action-5? > > <trackbot> ACTION-5 -- Olli Pettay to produce test template for D3E > -- due 2008-06-25 -- CLOSED > > <trackbot> [33]http://www.w3.org/2008/webapps/track/actions/5 > > [33] http://www.w3.org/2008/webapps/track/actions/5 > > Action-358? > > <trackbot> ACTION-358 -- Arthur Barstow to coordinate with Kai and > Dom -- due 2009-06-17 -- OPEN > > <trackbot> [34]http://www.w3.org/2008/webapps/track/actions/358 > > [34] http://www.w3.org/2008/webapps/track/actions/358 > > AB: Kai, is it safe to assume that Dom is in the loop that he's > checked on the License status? > > Kai: The copyright is probably my employer. But we're flexible > > <Marcos> /me hhmmmm... "Show evidence of wide review.".... wonder > how that will apply to Widgets Dig Sig. > > <scribe> ACTION: Art to work with Mike and Dom and Kai on the > license+copyright on the Test Suite [recorded in > [35]http://www.w3.org/2009/06/10-wam-minutes.html#action05] > > <trackbot> Created ACTION-359 - Work with Mike and Dom and Kai on > the license+copyright on the Test Suite [on Arthur Barstow - due > 2009-06-17]. > > AB: Kai, the spec that's most ready for testing is the Digital Sig > spec > > <scribe> ACTION: Art to ping TLR and FH regarding reuse of > XMLDigSig1.0 Test Suite [recorded in > [36]http://www.w3.org/2009/06/10-wam-minutes.html#action06] > > <trackbot> Created ACTION-360 - Ping TLR and FH regarding reuse of > XMLDigSig1.0 Test Suite [on Arthur Barstow - due 2009-06-17]. > > Kai: Do they have a test suite for 1.0? > > <tlr> the tests for 1.1 were very, very specific > > RB: They have one, there's been a requirement to reach PR to have a > test suite > > <tlr> strike 1.1, make that 2nd ed > > JS: tlr, is there a link? > > AB: The assumption is that we'd be able to leverage that test suite > > Kai: their suite should be simple, right? > ... and detached, applicable to SHA256 and x509.... > > <scribe> ACTION: Art to find or create examples of widgets digital > signature documents - helloWorld [recorded in > [37]http://www.w3.org/2009/06/10-wam-minutes.html#action07] > > <trackbot> Created ACTION-361 - Find or create examples of widgets > digital signature documents - helloWorld [on Arthur Barstow - due > 2009-06-17]. > > AB: Anything else on testing? > ... I think we should pause and look at anne's submissions > > <darobin> <anne> I don't like the link colour, it should be pink > > AB: Kai, would you walk us through an example? > > <anne> pink is dafunkz > > (Kai puts up his test framework) > > <[38]http://wtf.webvm.net/> > > [38] http://wtf.webvm.net/%3E > > Kai: Questions? > > MC: How do you record which assertion from the spec you've tested > > Kai: I've tried to name things sensibly > ... After the chapters of your specification > > <darobin> one example: > [39]http://www.w3.org/Graphics/SVG/1.2/Tiny/ImpReport.html > > [39] http://www.w3.org/Graphics/SVG/1.2/Tiny/ImpReport.html > > Kai: The Bondi Widget runtime is likely to be one of the two > interoperable implentations > > RT: Kai's statement was overly enthusiastic > > DA: it's a possible candidate > > AB: Meeting Adjourned > > RRSAgent: Make minutes > > Summary of Action Items > > [NEW] ACTION: Art to coordinate with Kai and Dom [recorded in > [40]http://www.w3.org/2009/06/10-wam-minutes.html#action04] > [NEW] ACTION: Art to find or create examples of widgets digital > signature documents - helloWorld [recorded in > [41]http://www.w3.org/2009/06/10-wam-minutes.html#action07] > [NEW] ACTION: Art to ping TLR and FH regarding reuse of XMLDigSig1.0 > Test Suite [recorded in > [42]http://www.w3.org/2009/06/10-wam-minutes.html#action06] > [NEW] ACTION: Art to work with Mike and Dom and Kai on the > license+copyright on the Test Suite [recorded in > [43]http://www.w3.org/2009/06/10-wam-minutes.html#action05] > [NEW] ACTION: Bryan to make a table (if it's easy) [recorded in > [44]http://www.w3.org/2009/06/10-wam-minutes.html#action03] > [NEW] ACTION: Marcos to define installation and instantiation > [recorded in > [45]http://www.w3.org/2009/06/10-wam-minutes.html#action01] > [NEW] ACTION: Mhanclik to investigate definitions of installation > instantiation in BONDI work [recorded in > [46]http://www.w3.org/2009/06/10-wam-minutes.html#action02] > > [End of minutes] > >
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Friday, 12 June 2009 11:54:55 UTC