Widgets F2F Meeting in Santa Clara CA US -- 02 Nov 2009

Date: 2 November 2009

<scribe> ScribeNick: ArtB

<scribe> Scribe: Art

Agenda Review

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

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 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> 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 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> 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: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0305.html

MC: I don't think there is an issue

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

- DRAFT -

Widgets F2F Meeting in Santa Clara CA US

02 Nov 2009

Attendees

Contents

Agenda Review

Widget URIs

Packaging and Configuration Spec

Summary of Action Items

Scribe.perl diagnostic output