Re: [widgets] Draft Minutes from 10 June 2009 f2f meeting

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]
>
>