Widgets F2F Meeting -- 10 Jun 2009

<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> 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> http://www.w3.org/TR/SVG11/struct.html#SwitchElement

<darobin> actually, this better: 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> 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> 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 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 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 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: http://dev.w3.org/html5/webstorage/

JS: No, but how you reference it.

<Marcos> 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> ... 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> http://www.w3.org/TR/widgets/ is going to LC again?

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: http://dev.w3.org/cvsweb/2006/waf/widgets-wm/

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 http://hasather.net/widgets/widgets.rnc : application, floating, fullscreen, mini, all

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"

<http://www.w3.org/TR/css3-mediaqueries/>

<www.w3.org/TR/css3-reader>

<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 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: 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> http://wtf.webvm.net/

scribe: That's the next thing I've been doing, with a guy named Robert from Opera

http://dabase.com/

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 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: 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> 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> 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 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 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 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)

<http://wtf.webvm.net/>

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

- DRAFT -

Widgets F2F Meeting

10 Jun 2009

Attendees

Contents

A+E spec

A+E spec - again ...

Window Modes / Query spec

Testing

Summary of Action Items

Scribe.perl diagnostic output