Date: 5 May 2008

<scribe> Scribe: Art

<scribe> ScribeNick: ArtB

<arve> he is

<MikeSmith> anne: yep

<MikeSmith> we are in the Sky Suite at the Radisson

<anne> MikeSmith, cool

<MikeSmith> tlr, is there are time when you can't call in for 1 hour or so today or tomorrow?

<tlr> when I *can't*?

<tlr> today 1130-1200, 1500-1530, 1600-1700 CET

Agenda Review

<MikeSmith> tlr: just wondering when we should schedule Widgets security discussion

<tlr> tomorrow 10-11. 15-16

AB: any comments about the agenda? http://www.w3.org/2006/appformats/group/May2008F2F

<tlr> I also believe you and I have a call at 7:30 cET tomorrow

<MikeSmith> tlr: remind me what call that is?

<tlr> see pm

<MikeSmith> ah

<MikeSmith> yep

<MikeSmith> tlr: so we will do the security discussion tomorrow morning

<MikeSmith> including digsig

TLR, we want you to join us tomorrow for Security Model and Dig Sigs. When are you available tomorrow?

ABe: let's do security tomorrow

MC: want TLR to join us for dig sig

Localization

MC: Arve and I talked about two diff models but we've only spec'ed one right now

AB: what you've spec'd now is section 5.4 http://dev.w3.org/2006/waf/widgets/#localization ?

MC: yes
... the idea is to be able to include various localized directories in one ZIP
... e.g. en/, es/, ...
... Signature file (signature.xml) can NOT be localized
... When the widget is opend, the "system environment" will provide the locale info (e.g. en, es, ...)
... If locale is explicitly set, the base will be set to the locales directory

ABe: need to be able to distinguish between those things that can be localized and those that cannot

CM: my concern is that changing the base has an odd effect; not sure changing the base is necessary

MC: config.xml can be a localized dir

BS: think we can use a relative URL; not sure you need an abs URL for everything

ABe: I'm starting to worry about this model because it's a bit complicated

MC: I don't think its too complicated but it's a bit odd

BS: I think it makes sense
... seems logical for us; it is easy to add a new locale

AB: I'm a bit concerned about the principle of least surprise but I agree it's relatively easy to add a new locale

ABe: I'm a bit concerned about scripts in this model

CM: what about adding CSS?

MC: it can be set in the localized base

CM: copies of CSS files i.e. one in each locale becomes a maintenance problem

MC: could have one master style sheet and then localized ones too

BS: that would be useful

<tlr> how about defining a pseudo directory CURRENT_LOCALE that can be used in references, but never exists in the zip package?

<tlr> (or something like that. ;-)

MC: we can talk about alternatives
... we can use document.write with a bunch of additional code
... some people like that approach

<tlr> document.write sounds like an even worse hack than a current locale directory

BS: that wouldn't be good

CM: agree

ABe: we could use URL templating of some form
... we could also do what FF does i.e. use ENTITY's

CM: URL template is something like what is done in Apache?

MC: I don't like model

AB: how close is this model to anything that is implemented today?

MC: this is close to Vista Sidebar model

BS: it's close to what Dashboard does

MC: it's kinda' of a mixture of different models

ABe: I'm reluctant about the re-basing

CM: I'm concerned the base shifting will create lots of confusion

ABe: other alternative - when the engine looks for a resource it should always first look for the localized resource
... if have jp and es folders and looking for icon, it would always 1st look in e.g. es/. If it didn't match it would then look at the root.

GG: it would create a merged virtual tree
... kinda works like CSS then in that the localized stuff overrideds the more general definitions

ABe: going back to the least surprise principle

MC: I think the current model meets that principle

BS: we need more information about how the model actually works

CM: think we should put it out for review

AB: was this model in the April 14 WD published on /TR/

MC: no, this was added last week

<MikeSmith> tlr: I just re-read out loud here your comment about CURRENT_LOCALE

Icons (Section 6.9)

MC: Benoit, you want a role attributue?

AB: icon element: http://dev.w3.org/2006/waf/widgets/#the-icon

MC: start with lowest res icon and then move up if available

BS: two places the icons can be used by the widget itself but also a widget can be associated with the author

ABe: isn't that more of a logo than an icon

BS: having an icon for the author could be useful

MC: I find that a bit "gimmicky"; not sure it's needed

BS: at Orange we use both icons
... if it is defined in the element it would be helpful

MC: we could add an attribute to the author element

ABe: if we're going to start adding things we should consider a thumbnail too

BS: yes, that would be helpful in something like a Widget gallery or directory

ABe: this disadvantage of including the thumbnail is that it bloats the ZIP

MC: for the author, should we just add an attribute?

BS: how about "img"?

AB: I am indifferent

MC: img is OK with me

RESOLUTION: we will add a "img" attribute to the author element

AB: how would we implement the thumbnail?

MC: just define a default file name "thumbnail"; it can be PNG, GIF, JPEG

CM: JPEG isn't really appropriate for an icon

ABe: I agree

MS: some handsets don't support JPEG
... at least generally

AB: do we want to limit to PNG and GIF?

CM: I think PNG only

ABe: but GIF can provide some animation

CM: we should remove JPEG

RESOLUTION: we will remove JPEG as one of the formats for the icon element and thumbnail files
... add thumbnail default file to the model

ABe: what about active and inactive roles for icons?
... e.g. hovering over an icon

MC: we've got an API for this so we're going to talk about it

BS: yes, Yahoo! does some interesting stuff in this area

CM: if we use SVG we get the scalability

BS: may want to super-impose two images on top of each other

ABe: but could be easier to use canvas on top of one of the images

MC: could get really creative and make the icon use XHR to dynamically change the icon

AB: are we OK with the three Default Icons rows we now have in Marcos' version?

MC: what version of SVG do we want as the reference?
... SVG 1.1 Basic

AB: I'm OK with that for now but will check our implementation and will report back if we want something different e.g. 1.2

Processing Model - Step 1

MC: step 1 is getting the Widget resource over HTTP or local storage
... some people may not like the way the spec is written
... it's patterned after the way HTML5 is written

MS: it is indeed oriented towards implementors; I understand that viewpoint and think it is OK

MC: Arve, Chaals - what do you think about this writing style?

CM: I think it's OK [but I don't have to implement it :-)]

ABe: I think including the implementation details is OK

<MikeSmith> for reference: http://dev.w3.org/2006/waf/widgets/#steps

MC: I have abstrated out the definitions from the processing

AB: I am generally OK with the approach but a bit concerned about giving this document to a localization expert. They won't be able to read the processing model as defined and will likely need some additionaly information.

BS: what process is needed for registering the Media Type?

AB: the IETF and W3C have an agreement where the definition can now be done directly in a Recommendation; we do not need to create a new RFC.

<scribe> ACTION: Art Work with Mike to determine what we needs to be done to register application/widget [recorded in http://www.w3.org/2008/05/05-waf-minutes.html#action01]

<trackbot-ng> Created ACTION-175 - Work with Mike to determine what we needs to be done to register application/widget [on Arthur Barstow - due 2008-05-12].

RR: I have a question about the Request example - should the */* be there?

MC: good point; I'll remove it

Proc Model Step 2

MC: this section contains the details about how to verify the ZIP archive and its file entries

<MikeSmith> [in regard to registering a new media-type, I found the following: http://www.w3.org/2002/06/registering-mediatype.html]

AB: what about the ZIP signature requirement?

MC: they use different signature mechanisms then what we define in our Signature spec

Proc Model Step 3

MC: this step defines the default configuration values

RR: I think you've got width and height switched

MC: OK; I'll fix this
... want to discuss the plugins issue

CM: not sure 300 (w) x 150 (h) is good for phones

ABe: I think a sensible default is needed in some cases

BS: I need to be able to specify width and height for some of our use cases
... developers need some control about this

<MikeSmith> action-175?

<trackbot-ng> ACTION-175 -- Arthur Barstow to work with Mike to determine what we needs to be done to register application/widget -- due 2008-05-12 -- OPEN

<trackbot-ng> http://www.w3.org/2005/06/tracker/waf/actions/175

ABe: also want to talk about Chrome e.g. menus, sidebars, etc.

MC: we'd need to define what chrome means

ABe: prefer an attribute that says chrome or no chrome
... this can affect window size

AB: you want a binary attribute?

ABe: yes
... think about this as a way to distinguish a widget from something like an AIR app
... the width and height would not be useful when a window manager is involved

MC: so an attribute like "chrome" or "window"

BS: I prefer to use window

ABe: let's look at what Adobe specifies with Air
... i.e. in the manifest

<arve> bhttp://livedocs.adobe.com/air/1/devappshtml/

<arve> http://livedocs.adobe.com/air/1/devappshtml/WorkingWithWindows_2.html#1038168

<arve> "You can set the systemChrome property to standard or none. Choose standard system chrome to give your window the set of standard controls created and styled by the user's operating system."

AB: what do we want to specify here re. chrome/window ?

ABe: the important thing is -> what does it do?

AB: who wants this?

ABe: we do

BS: we want this to

MC: is it important enough for v1.0?
... for some existing systems like Nokia Web Run-time widgets, there is only full-screen

AB: yes, I would expect some implemenations to ignore this attribute if they only implement full-screen

MC: propse attribute "mode" with values application, fullscreen and floating

AB: what's the diff between application and floating?

MC: application implies chrome

CM: application is a widget

ABe: could do 3 separate boolean attrs: chrome or not, fullscreen or not and transparency or not

MC: new proposal for these attr values are: window, fullscreen and default

AB: should we try to define these values now?

MC: Window means chrome: resizeable and closable
... fullscreen: no chrom, no resize
... default: floating window
... floating: dragable, author resizeable via code
... [MC updates the text for this attribute "live" ...]

Widget Addressing Scheme (digression from the Proc Model)

MC: we need some mechanism to access the contents of a Widget resource

ABe: need a unique id per widget instance

MC: was thinking about a new scheme "widget:"
... thus widget://[instance ID1]/index.html

AvK: when would this new scheme be used?

MC: one use case is a image e.g. <img src="widget://images/logo.gif">

AvK: would need a resolve URI

ABe: need it for checking DOM attributes

MC: it either resolves to file:// or something like widget:// - we need a full URI

AvK: do you need a new scheme or define a new API

ABe: agree an API could be used

MC: we need something like this and need to think about it some more

GG: could we use the widget's base where it was downloaded?

AB: what's the existing practice?

MC: I don't think anyone is doing it correctly. Perhaps Dashboard is doing something but I'm not sure.

ABe: we do something now using a scheme and a unique identifier
... we've done this for security reasons; it would be extremely difficult for us to change our implementation

MC: when the URIs are "exploded" they must conform to the URI spec

AB: where can we find the details?

ABe: it's in the security spec.

<MikeSmith> back from lunch

Platform Attribute

MC: see my proposal from last month: http://lists.w3.org/Archives/Public/public-appformats/2008Apr/0086.html

ABe: this seems close to version metadata

MC: it's similar but could be useful in the future
... we need it after 1.0 is out

ABe: then shouldn't we wait until we really need it?

CM: I'm not a big fan of it

RR: what's the precedence?

MC: it is implemented in a couple of implementations today

<anne> Food: http://www.pacificspirit.com/blog/2007/10/02/ireland_restaurant_reviews

MC: prior work: Konfabulator (minVersion), Vista Sidebar Gadgets (minPlatformVersion),
... and Google Desktop gadgets (minimumGoogleDesktopVersion).

RR: is this for forward or backward compat?

CM: I don't think we need to solve this problem yet
... it would imply a certain set of capabilities

AB: it would be optional, right?

MC: yes it would be optional

AB: how strong do you feel about this Marcos?

MC: I'm OK with removing it now but it will be needed later

Widget Addressing Scheme [Part II]

MC: I'd like to come back to this topic

[Pause while Marcos checks in his draft.]

MC: I want people to send us some feedback

AB: is there any specific group we want to ask for review?

MC: let me spec it up first and then we can publish it and get feedback

Plugins (Step 3 in the Processing Model)

MC: support for plugins varies quite a bit

ABe: a plugin could be anything that embeds content and has a sec model that is implemented by the player
... we can add this to the topic list for Thomas

GG: I think it makes sense to have it; agree it could be a potential secuirty hole but an implementor could just decide not to support them
... Perhaps the name should be "usePlugins"

MC: I propose then we leave it in

AB: any objections?

ABe: no, but I think we'll need to discuss this when we talk about the Security Model

CM: what exactly is a plugin in this context?

MC: see Arve's definition

ABe: I think we the spec needs to clearly define the term plugin

Topic <content> Element

MC: see http://dev.w3.org/2006/waf/widgets/#the-content

ABe: we need to clarify how it relates to internationalization

MC: agree it needs to be specified e.g. relative URI vs. absolute URI

ABe: what happens if there is more than one content element?

MC: take the first one; non-fatal

Width and Height attributes [re-visited]

CM: should we add an Issue about the defaults?

MC: we could change it to 100x100

AB: any objections?

[None]

Step 4 of the Processing Model

MC: this section states how to locate the digital signature
... the file must be named signature.xml

ABe: I think this step and Step 5 should say what happens if the signature is in error/in-valid

RR: why the case insensivity?

MC: just to be more friendly

RR: is there a general policy regarding casing?

MC: yes, the spec is consistently case insensitive

AB: Step 5's OK?

MC: yes, it just says see Dig Sig spec

Step 6 of the Procssing Model

MC: this is about locating the config doc and determining the "base URI"

AB: so this just says, the more specific config file wins, right?

MC: yes

AB: is this algorithm copied from somewhere else?

MC: yes, it's from RFC3066
... this has been superceded by RFC4646 but that later spec is overkill AFAIConcerned
... for example en-us-{dialect}
... we may want to directly refer to the truncation algorithm in RFC4646; I'll investigate

Step 7 of the Processing Model

MC: Step 7 is now locating the Configuration Document
... model is to look in the localized folder first, drop to the mount point and look for it there; if not there, look for start file ...

AB: any questions?

[None]

Step 8 of the Processing Model

MC: this is the lengthy step where the Config Doc is processed
... <widget> must be in the appropriate namespace or the UA dies
... In most cases errors are ignored; want to minimize the number of fatal errors
... If an element occurs 0 or 1 and the first one is in error, a subsequent element will be used (if found and not in error)

ABe: what about whitespace for <license>

CM: could use XML's whitespace=preserve

MC: OK, I'll add that to the Proc Model

AB: Marcos, at one point you mentioned you were working on a Java-based implementation. How's that going?

MC: I haven't worked on it lately; did some work on the Dig Sig spec
... I'll plan to contribute it to the WG's reference implementation

AB: what is the provenance of the Non-negative integer algorithm?

MC: HTML5. And the White-space algorithm as well.

AB: what about the content type sniffing

MC: we just follow the rules from GIF87, GIF89 and PNG
... Chaals, how to sniff SVG for the icon type?

CM: just look for the SVG namespace

<shepazu> or the MIME Type...

MC: let's look at the Default Start Files table

ABe: should index.xml be added?
... perhaps the MIME types are needed at all

CM: I'd like to see this table much shorter i.e. just index.html and index.htm
... remove the SVG and don't add XML

Processing Model: Step "Locating the Base folder and Start File"

ABe: I don't necessarily like the use of "mount point"

MC: the idea is we have a virtual mount point

CM: I don't particularly like but can live with it

BS: what about Widget Root?

AB: that's OK with me

RESOLUTION: mount point changed to Widget Root

Processing Model Step "Locate the default icons"

MC: order is: PNG, GIF, SVG

CM: if SVG is supported then presumably would want to first search for SVG

[MC changes the spec so if SVG is supported and a SVG image is included, it will be used (first priority).]

CM: if someone goes through the effort to create a SVG icon it should be used

AB: I'm OK with Chaal's proposal
... any objections to stating to use SVG if it is supported?

[No objections]

Displaying Icons

MC: the text in the latest ED is bit out of date, particularly based on what we've stated before

CM: SVG spec covers some of the requirements here for displaying icons of various sizes
... not the preserving aspect ratio section

MC: I'll look at the SVG; I may just have keep this section as guidance to rendering engines
... but may need some guidance for authors too

BW: it would be nice if the icons could be stylized e.g. by CSS to have "rounded edges"

BS: another feature is active icons
... although I think that type of feature should be optional (at least for now)

CM: animation is not the same as interaction

ABe: SVG also brings up other issues e.g. being able to create socket() connections

CM: perhaps we should add a note requesting feedback re SVG

[Marcos adds such a note to his local Editor's Draft]

Processing Model "Instantiating the Start File"

AB: do we want to discuss this now?

MC: I think there are some security implications so I prefer to defer discussions until tomorrow
... I don't know how much detail we need here
... I think HTML5 spec has some relevant text

CM: SVG also has some relevant text re Rendering Context

ABe: I don't think we need to say much here re Rendering Context

FlowChart from April 2007

BS: I like the flow chart that was in one of last year's versions was very useful

MC: it's out of date

BS: I think it was helpful and would like to see it added

CM: I agree something like this would be useful

AB: anyone want to help Marcos?

[No volunteers ...]

MC: I'll put it on my list of things to do

Summary of the Packaging and Config spec

MC: When I finish my pending updates (in about two weeks or so), I think we're mostly done
... we *really* need IN DEPTH REVIEW
... Lachlan said he'll do a review
... we need other reviewers too

AB: what are your thoughts about the P&C spec vis-a-vis the Security Model input?
... For example are they separated docs?

MC: yes, I think so.
... I think the P&C is kinda' "dumb".
... The Security Model wraps around the P&C

ABe: yes, I concur

<Benoit> should we propose another meeting between now and oct 20

<Benoit> ?

Next F2F Meeting

AB: I proposed we meet during the TPAC meeting Oct 20-25

ABe: I prefer early September

MC: After July 25 I will be back in Europe @ Oxford
... my commitment at Oxford ends July 27

ABe: needs to be after July 15

CM: I need to consider the upcoming XDR/XHR2 meeting in the US

MS: I will take a break sometime between mid-July and end of August
... beginning of Sept would be OK
... beginning of July would be OK

BS: I think we host in Paris

CM: I could possibly host in Madrid

GG: no particular black out dates

BS: between the last week of July and first three weeks of August I will not be available for two weeks

<Benoit> at least 2 weeks

AB: Meeting Adjourned

This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/... having multiple/CM:/
Succeeded: s/handsets/some handsets/
Succeeded: s/is the fwd/is this for forward/
Succeeded: s/to creae a/to create a/
Succeeded: s/some relevant text/some relevant text re Rendering Context/
Found Scribe: Art
Found ScribeNick: ArtB
Present: Art Marcos Arve Guido Mike Benoit Chaals Richard Anne Ben
Agenda: http://www.w3.org/2006/appformats/group/May2008F2F
Found Date: 05 May 2008
Guessing minutes URL: http://www.w3.org/2008/05/05-waf-minutes.html
People with action items: art mike with work