See also: IRC log
<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
<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> <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> 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
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
<ArtB> ScribeNick: timeless_mbp
<ArtB> Window Modes: http://dev.w3.org/cvsweb/2006/waf/widgets-wm/
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].
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/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)
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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) WARNING: Bad s/// command: s/int/init/ ? Succeeded: s/investigation/investigate/ Succeeded: s/strorage/storage/ Succeeded: s/deal with it/deal with requestFeature/ WARNING: No scribe lines found matching ScribeNick pattern: <Art> ... Found ScribeNick: ArtB Found Scribe: Art Found ScribeNick: drogersuk Found ScribeNick: abraun Found ScribeNick: JereK Found ScribeNick: timeless_mbp ScribeNicks: ArtB, drogersuk, abraun, JereK, timeless_mbp Present: Benoit Mike Josh Jere Robin AndyB Marcos DanA David Laura Marcin Magnus Kai Agenda: http://www.w3.org/2008/webapps/wiki/WidgetsLondonJune2009 Found Date: 10 Jun 2009 Guessing minutes URL: http://www.w3.org/2009/06/10-wam-minutes.html People with action items: art bryan marcos mhanclik[End of scribe.perl diagnostic output]