- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Fri, 12 Jun 2009 06:45:10 -0400
- To: public-webapps <public-webapps@w3.org>
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]
Received on Friday, 12 June 2009 10:46:07 UTC