W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

[widgets] Draft Minutes from 10 June 2009 f2f meeting

From: Arthur Barstow <art.barstow@nokia.com>
Date: Fri, 12 Jun 2009 06:45:10 -0400
Message-Id: <02FA1CF2-A7A1-473D-A3DF-3CA021DBD9F7@nokia.com>
To: public-webapps <public-webapps@w3.org>
The draft minutes from the June 10 Widgets f2f are available at the  
following and copied below:


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  

-Regards, Art Barstow


       [1] http://www.w3.org/

                                - DRAFT -

                           Widgets F2F Meeting

10 Jun 2009


       [2] http://www.w3.org/2008/webapps/wiki/WidgetsLondonJune2009

    See also: [3]IRC log

       [3] http://www.w3.org/2009/06/10-wam-irc


           Benoit, Mike, Josh, Jere, Robin, AndyB, Marcos, DanA, David,
           Laura, Marcin, Magnus, Kai




      * [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
    ... 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?

    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

    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

    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

    <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


      [13] http://lists.w3.org/Archives/Public/public-webapps/ 

    <abraun> AB: where less important than that it is done and is

    <abraun> general concern about scope creep delaying P&C

    <abraun> ACTION: Marcos to define installation and instantiation
    [recorded in

    <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

    <trackbot> Created ACTION-356 - Investigate definitions of
    installation instantiation in BONDI work [on Marcin Hanclik - due

    <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

    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

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

    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

    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

    (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/ 

    MH: hasFeature is about access to config.xml
    ... if something is required and it's not there, the widget is not

    MC: Does not tell you everything

    JS: You always only get information you already know from

    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
    ... 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/


      [22] http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-wm/ 

    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/%3E


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

    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

    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

    Benoit: we put in ResolutionEvent in Paris because it needed to be
    ... 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

    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

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

    (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
    ... 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

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

    (many hands raise)

    scribe: Widget Tests!. So I started months ago
    ... Marcos told me that some things were stable, so I started

    <DKA> Web Compatibility Test for Mobile Browsers:

      [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/


      [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

    Kai: I use git and dump to Dom, and he pushes to CVS

    <scribe> ACTION: Art to coordinate with Kai and Dom [recorded in

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

      [32] http://www.w3.org/2005/10/Process-20051014/ 

    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


    <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


    <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

    <trackbot> Created ACTION-359 - Work with Mike and Dom and Kai on
    the license+copyright on the Test Suite [on Arthur Barstow - due

    AB: Kai, the spec that's most ready for testing is the Digital Sig

    <scribe> ACTION: Art to ping TLR and FH regarding reuse of
    XMLDigSig1.0 Test Suite [recorded in

    <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

    <trackbot> Created ACTION-361 - Find or create examples of widgets
    digital signature documents - helloWorld [on Arthur Barstow - due

    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/%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

    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
    [NEW] ACTION: Art to find or create examples of widgets digital
    signature documents - helloWorld [recorded in
    [NEW] ACTION: Art to ping TLR and FH regarding reuse of XMLDigSig1.0
    Test Suite [recorded in
    [NEW] ACTION: Art to work with Mike and Dom and Kai on the
    license+copyright on the Test Suite [recorded in
    [NEW] ACTION: Bryan to make a table (if it's easy) [recorded in
    [NEW] ACTION: Marcos to define installation and instantiation
    [recorded in
    [NEW] ACTION: Mhanclik to investigate definitions of installation
    instantiation in BONDI work [recorded in

    [End of minutes]
Received on Friday, 12 June 2009 10:46:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC