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 ".pñg", 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 ".pñg".
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]
