W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

[widgets] Draft Minutes for 2 November 2009 f2f meeting

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 3 Nov 2009 21:44:19 -0800
Message-Id: <148518D1-7BB1-4E90-A1EF-DD32A0516421@nokia.com>
To: public-webapps <public-webapps@w3.org>
The draft minutes from the November 2 Widgets f2f meeting are  
available at the following and copied below:

  http://www.w3.org/2009/11/02-wam-minutes.html

WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before November 12 (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 in Santa Clara CA US

02 Nov 2009

    [2]Agenda

       [2] http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Monday. 
2C_November_2

    See also: [3]IRC log

       [3] http://www.w3.org/2009/11/02-wam-irc

Attendees

    Present
           Art, Marcos, Benoit, Magnus, Larry, Josh, Marcin

    Regrets
    Chair
           Art

    Scribe
           Art

Contents

      * [4]Topics
          1. [5]Agenda Review
          2. [6]Widget URIs
          3. [7]Packaging and Configuration Spec
      * [8]Summary of Action Items
      _________________________________________________________


    Date: 2 November 2009

    <scribe> ScribeNick: ArtB

    <scribe> Scribe: Art

Agenda Review

    AB: Agenda is
    [9]http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Monday.2C_Nov
    ember_2
    ... any change requests?
    ... the agenda includes some specs that will not be on the agenda

       [9] http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Monday. 
2C_November_2

    BS: when does widgets meet with DAP?

    AB: today 15:30-16:30

    BS: on a recent call, we talked about widgets and html5 and caching
    ... think this is something we need to state
    ... eg where do we define that
    ... we don't have to take it now but should figure out who are the
    right people to chat

    AB: can you take an action to define the problem statement?

    BS: I'm not that familiar with that subject

    MC: I think the topic is well known

    BS: but has the interaction been stated or defined?

    MC: they just work together

    AB: I think we need to differentiate overlapping specs and
    synergistic usage of HTML5 specs

    MC: we don't create overlapping specs with HTML5

    AB: how do we want to handle this?
    ... put it on the agenda of a VC?

    MC: I think we've talked about this before
    ... we can talk about App Cache's uses by widgets

    AB: on the way to SFO I created
    [10]http://www.w3.org/2008/webapps/wiki/Coordination

      [10] http://www.w3.org/2008/webapps/wiki/Coordination

    <timeless> if a wua is online and doesn't offer caching, will the
    widget author complain?

    AB: this is intended to capture various "coordination points"

    <Marcos>
    [11]http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Monday.2C_No
    vember_2

      [11] http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Monday. 
2C_November_2

    [ Art adds a new "Widgets and HTML5" section to the Coordination
    wiki ]

    MO: what about HTML4

    MC: we have a dependency on some parts of HTML5

    MO: at least one of the widgets specs references an HTML5 spec

    MC: yes, the TWI spec references Web Storage
    ... it does mean we can't progress to REC until Web Storage is more
    mature

    AB: re plans, I added a new Plans column to our PubStatus page
    [12]http://www.w3.org/2008/webapps/wiki/PubStatus

      [12] http://www.w3.org/2008/webapps/wiki/PubStatus

    <Benoit> great

    AB: this provides useful data to the WG and the Public
    ... my expectation is that by the end of the day tomorrow, the Plans
    will have the best data we have for each of WebApps specs
    ... Hixie told me a week or so ago he expects Web Storage to be
    ready for LC in November
    ... I believe that spec already has a number of impls

    MC: that was true but isn't so any more given the new Structured
    Clones stuff that has been added
    ... with structued clones can now store more complex structues
    ... and it has no serialization syntax

    AB: we will discuss TWI spec tomorrow morn for 1.5 hours
    ... we should add Web Storage status and related discussions
    ... I'm not convinced we must have that dependency on Web Storage
    ... apparently Opera thinks otherwise

    MC: yes, that's true

Widget URIs

    AB: we decided not to include this spec on this week's agenda for a
    couple of reasons:

    <Benoit> [13]http://dev.w3.org/2006/waf/widgets-uri/

      [13] http://dev.w3.org/2006/waf/widgets-uri/

    AB: 1. the LC comment period doesn't end until Nov 10
    ... 2. the Editor, Robin Berjon, is Chairing the DAP WG meeting on
    Nov 2-3
    ... 3. We discused this during our Oct 29 weekly call and Robin
    stated he would look for Larry this week

    LM: does anyone have any comments

    AB: this is a great idea
    ... I'm expect more comments and wanted to queue them up to take
    them all at once

    LM: my comments aren't from the TAG
    ... want to know if it meets the guidelines for a new scheme

    MC: I share some of your concerns

    AB: I'm OK with talking about it but it's highly likely the
    conversation will need to be replayed when Robin is available
    ... I too am concerned about whether or not we've reached the
    threshold where a new scheme is needed

    LM: there is no scheme that works as is
    ... I don't think the new scheme issue is so great
    ... although for some TAG members it is
    ... need to think about authority
    ... there are some things like authority that must be tightened
    ... that leads to security issues

    MC: we have ZIP relative paths

    LM: need to look at it from the view of is it really going to work

    MC: we don't control the ZIP spec
    ... we do try to clarify it

    LM: can profile it
    ... W3C doesn't have to support every feature of ZIP
    ... ease of impl should not take priority over interoperability

    MC: the P+C spec defines the Zip relative path

    LM: who is the audience for the URI scheme?

    MC: supposed to be private to the widget instance

    LM: so then, why do you need it?

    MC: one reason is because we don't want people to use file:

    LM: that's not a good reason
    ... if you have real interop problem that's one thing

Packaging and Configuration Spec

    AB: MC and MH have been debating valid Zip relative path for some
    time now
    ... want to get consensus here if there is an issue or not
    ... we should not publish LCs if we have open issues

    MC: let's look at the e-mail ...

    AB: here's the last email from MH:
    [14]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/03
    05.html

      [14] http://lists.w3.org/Archives/Public/public-webapps/ 
2009OctDec/0305.html

    MC: I don't think there is an issue

    <Marcos>
    [15]http://dev.w3.org/2006/waf/widgets/#rule-for-identifying-the-med
    ia-type-of-a

      [15] http://dev.w3.org/2006/waf/widgets/#rule-for-identifying- 
the-media-type-of-a

    [ We look at section 9.1.10 of LC#3 ]

    JS: please make sure the Examples use the same amount of indentation

    <timeless_mbp> example: .topos.db is a SQLite format 3 binary file

    <timeless_mbp> .knips.xml

    <timeless_mbp> but ... those should be .db and .xml

    <Marcos>
    [16]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/02
    99.html

      [16] http://lists.w3.org/Archives/Public/public-webapps/ 
2009OctDec/0299.html

    JS: not sure basename is a good tool to use here
    ... in terms of helping us understand what the spec should say

    <timeless_mbp> in test/.jpg => "test/" is a directory path

    <timeless_mbp> basename's job is to by default strip out directory
    components from a path to a file

    <timeless_mbp> yielding simply the filename portion of the path

    MC: perhaps we should have sent everything to sniff and not do the
    optimizations

    <marcin2> is it ok to come now?

    <timeless_mbp> yes

    MC: we added this as a request from Mozilla

    <timeless_mbp> the second argument to basename is for telling
    basename what extra thing to strip from the filename

    AB: was that Henri?

    MC: yes Henri and perhaps Jonas too
    ... I think the algorithm we defined is OK
    ... we've gone thru the cases
    ... are you OK with this JS?

    JS: yes, it seems OK

    MH: I'm OK with dot something is a file
    ... think the Proc Model needs to be changed
    ... we don't need ranges

    <timeless_mbp> If any character in the extension is outside the
    U+0041-U+005A range and the U+0061-U+007A range, then go to step 10
    in this algorithm.

    <timeless_mbp> For example, if the extension is ".pg", the go to
    step 10 in this algorithm.

    <timeless_mbp> 10 = #

    <timeless_mbp> Let content-type be the result of processing file
    through the [SNIFF] specification.

    <timeless_mbp> 11 = # Return the value of content-type.

    <timeless_mbp> note that the current specification ended up w/
    bullets instead of numbers which caused us problems :(

    MH: we don't need the ranges

    MC: why not?

    MH: won't be able to create test cases for this

    MC: yeah, I guess that's true
    ... it is an optimization so it could be removed

    MH: can case-insensitively match

    MC: yes, can do it that way
    ... yes, I guess this can be viewed as over-specified
    ... I don't see any harm
    ... that is no harm, in keeping it

    MH: but we don't need it

    AB: we will need to think about its affect on the impl
    ... can you MC live with removing it?
    ... I would prefer to err on the side of simplicity i.e. to remove
    it

    MC: if we remove it, it will not affect implementations because it
    is an optimization

    JS: in fact we are defining case-insensitive

    MC: this algorithm is just to match the table of ~10 extensions

    MH: sniff has another table for extensions
    ... we typically have UTF-8

    JS: case insensitive is not well-defined
    ... should clarify why the A, B, C and examples are in the spec

    MH: is case sensitive defined in Unicode

    <Marcos> [17]http://unicode.org/reports/tr10/

      [17] http://unicode.org/reports/tr10/

    MC: its complex; see Unicode Collision Alg

    AB: so we are now saying the text will remain but clarified i.e. why
    those sub-steps are there?

    MC: yes

    AB: MH, can you live with that?

    MH: yes, if the text is clarified

    AB: MC, what have you changed?

    MC: I changed the Example between A. and B.

    <timeless_mbp> This would probably be implemented by scanning the
    filename from right to left searching for non-ascii or
    <ascii-period>. at the first instance of non-ascii, bail

    <Marcos> The above step is precisely here to handle case comparison
    for file extensions such as ".pg".

    AB: if we get consensus on this issue, I want to record a Resolution
    ... any objections to the text MC proposes above?

    JS: need to be careful where it is inserted

    AB: any objections?

    [ None ]

    RESOLUTION: the text MC proposes above addresses the issue MH had re
    the extension algorithm

Summary of Action Items

    [End of minutes]
Received on Wednesday, 4 November 2009 05:44:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT