Widgets Voice Conference

26 Mar 2009


See also: IRC log


Art, Thomas, Frederick, Mark, Andy, Robin, Arve, Marcos
Jere, Bryan




<scribe> ScribeNick: ArtB

<scribe> Scribe: Art

Date: 26 March 2009

Review and tweak agenda

AB: I posted the agenda on March 25 http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0926.html Note DigSig is not on today's agenda.
... Are there any change requests?

FH: want to add DigSig namespaces

AB: OK but will limit the time
... any other requests?



AB: any short announcements? I don't have any.

[ None ]


AB: go ahead Frederick

FH: I made a few changes
... checker complained

MC: will fix it

FH: namespace question
... is it OK to not use date

TR: I need to check the namespace policy

<tlr> http://www.w3.org/2005/07/13-nsuri

RB: namespace policy should permit this

TR: I don't see any problems; we can go ahead

FH: then I think we're all set

MC: agreed

AB: the DigSig WD should be published early next week

P&C spec: L10N model

AB: one of the open issues is if the P&C's localization model should be one master config file only versus a master config file plus locale-specific config files to override definitions in the master config file. Marcos created lists of advantages and disadvantages of both models. Some people have expressed their preference. The tally appears to be: Only one: Marcos; One Plus: Josh, Benoit; Can Live With Either: Jere. The thread is here: <http://lists.w3.org/Archi
... I would like to get consensus i.e. a resolution on this today and a gentle reminder that "I Can Live With It" will help us get the next LCWD published. Let's start with Marcos - do you see a single model that addresses everyone's concerns?

MC: the new model doesn't address the concern where multiple localizers are involved in the process pipeline
... the new model is easier to implement
... agree the config file could grow to an un-manageable size
... the I18N WG said the new model is OK
... I think we could merge the models

BS: I don't understand the merge model Marcos

MC: have the main config file but if the app has lots of localized data that data can be put in separate files

AB: any other comments?

<w3c_> when using both models there would need a sort of precedence of some sort so that 2 information do not overlap

RB: so is the idea to have a single file for v1.0 and then in v1.* move to support the old model

MC: yes, that is true

<darobin> RB: I think it makes sense to start with something simple and only add the more advanced features if we need them later

MC: the model is to use a single config doc for 1.0
... inside that file the xml:lang attr is used to localize specific elements and attrs
... in subsequent version of P+C we add support for locale-specific conf files

AB: is this right Marcos?

MC: yes

AB: any comments about this evolution path
... Note that timeless is not on the call
... He objected to the new model but did not include any rationale for his objection
... Benoit, what are your thoughts on this evolution proposal?

BS: I think I can live with it
... I do think localizers having their separate files is better
... but having just one config file wil be easier for the developer

AB: I think we have consensus to go forward with Marcos' proposal
... draft resolution: for v1.0 we will use the new l10n model proposed by Marcos and consider multiple locale-specific config files for the next version
... any objections?

[ None ]

RESOLUTION: for v1.0 we will use the new L10N model proposed by Marcos and consider multiple locale-specific config files for the next version

P&C spec: status of <access> element:

AB: last week the <access> element was noted as an open issue that must be addressed before we can publish a new LCWD. http://dev.w3.org/2006/waf/widgets/#the-access-element If I recall correctly, no one volunteered to submit any related inputs. The note in the ED says "ISSUE: This element is currently under review. A new proposal will be available in the next few days that will provide the ability to list which URIs can be accessed.".
... Marcos, what is the status and what specific inputs are needed?

MC: I am researching how to address this
... looking at what Opera does

<Marcos> I need to align it with http://homer.w3.org/~connolly/projects/urlp/raw-file/008373680cae/wah5/draft.html

MC: but we probably will want to do something a bit different
... the above is by Dan Connolly

TR: what alignment with DC's draft is needed?

MC: need to align with terminology
... need to break up the scheme parts to diferent attrs
... e.g. port can be a list

TR: this is similar to some work in POWDER WG
... wonder if this needs to depend on the URLs in DC's work
... but we can take it to e-mail
... doing this should take a week or two and will require some changes

RB: can we please get a pointer to POWDER work?

TR: will get one; not sure if there needs to be a dependency
... we should take this to e-mail

MP: we previously discussed a hybrid approach
... and then define some precedence rules if there are conflicts in host elements
... for v1 can we just go with URI
... and if a hybrid approach really is needed we do that in a subsequent version of the spec
... What do you think about that approach?

MC: could be a prob in some use cases
... some web apps have many subdomains
... then those couldn't be accessed

RB: but could use *.foo

MC: yes, that's an option

<darobin> RB: e.g. http://*.googlemaps.com

AB: any last comments before this discussion moves to the mail list

MC: if we use wildcards, it opens a different set of questions
... e.g. what part of the scheme are "*" permitted

RB: typically, don't need too many ports
... want to start with something simple for v1
... and possibly ask for more feedback

AB: please take the discussion to the mail list
... MC, can you make a short proposal on the mail list?

MC: yes I will
... re wildcarding, CORS tried this and it didn't really work

P&C spec: <update> element given Apple's patent disclosure

AB: Apple's disclosure raises the question "what, if any, changes must be made to the P&C spec?" where one major concern is if P&C has a dependency on Updates. There appear to be two relevant pieces of text: Section 7.14 (<update> element) http://dev.w3.org/2006/waf/widgets/#the-update-element and Step 7 http://dev.w3.org/2006/waf/widgets/#step-7-process-the-configuration-document.
... My take is that Section 7.14 is OK as written given what we know today (PAG hasn't even had its first meeting). The element's processing in Step 7 could be qualified with something like "this step is only performed if the UA implements [Widgets Updates] but I can live with the existing text.
... One other option is to put a Warning in 7.14 e.g. "Warning: this feature may be removed because ...".
... what are people's thoughts on this?

BS: without any info from the PAG, I think we should keep it and add some type of warning

TR: is the question, how far can the spec go given the PAG?
... I think the group cannot go beyond LC but will verify with Rigo

AB: the syntax is in the PC spec but the proc model is in the Updates spec

MC: yes that is correct
... we could remove <update> element from P+C and define it in the Updates spec

AB: any comments on Marcos' proposal?
... I like that proposal

BS: I would be opposed to it

TR: I will discuss this Rigo and cc member-webapps

<Benoit> but I do not want to hold the P&C spec with this

TR: I can understand the concern about a normative ref for a spec that may be stalled

AB: we will wait for some feedback from TR and Rigo before we implement MC's proposal

P&C spec: step 7 - need to add <preference> element and the <screenshot> element;

AB: last week <preference> and <screenshot> were noted as needing work. I believe Robin agreed to help with this. What is the status and plan? http://dev.w3.org/2006/waf/widgets/#step-7-process-the-configuration-document

RB: I haven't made a lot of progress on this

MC: I will try to finish this by tomorrow
... I have been blocked by the consensus on the L10N model
... but now that we have that consensus, I can make the appor changes

P&C spec: XML Base

AB: Thomas and Marcos have exchanged some emails about this http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0883.html What is the status and what specifically needs to be done to address the issue?

MC: this relates to the L10N model too
... the xml:lang value needs to match the name of a localized folder
... TR is wondering if XML base is the right solution for this
... there are some other related issues too; I've been talking to Robin and others in Opera about this
... Not having a URI scheme for widgets cause problems too
... ZIP relative paths are not URIs

TR: we want a model to make refs from within the html
... but mapping URI refs to something else
... using XML base is not going to help
... as it confuses the left and right sides of the mapping
... The spec lang MC wrote redfines XML base

MC: I still want to try to solve this with XML Base
... our solution will have to work with HTML base

TR: if there is a URI scheme defined that points at things within the widget
... then we can use that URI scheme throughout

MC: yes

TR: does the base paramter sit on the URI side of the mapping or the other side
... similar to some questions we had about References in DigSig
... struggling with a missing design decision
... there are two things: uri ref and the other is paths to the zip
... think most things should be in URI side but some things should be on the zip side
... Need to get some consistency in the various specs

RB: agree we must solve this problem

<tlr> RB: metadata files will feel more comfortable in URI space

<tlr> TR: This is another instance of the URI discussion. We have some things that live in URI space. We have some things that live in Zip path space. We need to do a translation between the two and say where that happens.

<darobin> RB: we have to solve this anyway for the content of the widgets (HTML, SVG), so since we need to solve it, and since it would be more comfortable to use URIs in config.xml we ought to solve it once and use it everywhere

<tlr> TR: Right now, we're reinventing that translation over and over again. That way lies madness

AB: other than "take this to the mail list", who is going to do what to help us get closure here?
... any last comments?

A&E spec

AB: the latest ED of the A&E spec includes many Red Block Issues. I'd like to go thru as many of them at a high level and for each of them get a sense of what specific inputs are needed and the plan to get those inputs. Latest ED is: http://dev.w3.org/2006/waf/widgets-api/

Arve: Marcos, the latest ED says 25 March but I don't think it is the latest version

AB: yes, I was wondering the same thing

Arve: should we go thru all of the Red Blocks?

AB: I want to understand what needs to be done

Arve: re Window issue
... who can talk to HTML WG

RB: I think Window will be split out as soon as an Editor is identified

MC: but no one has agreed to be the Editor

AB: so what does this mean in terms of the progression of this spec?

MC: I don't think we need a depedency on the Window spec
... We can just add some text about the "top level ... "

Arve: yes, we can make it informative ref

<darobin> http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window

TR: agree, it can be Informative ref

AB: do we consensus the dependency is an Informative ref?

Arve: yes
... I can re-write this Red Block
... I only want a DOM 3 Core ref and Widget ref but nothing else
... and XHR as is done already

AB: any objections to Arve's proposal?

RB: that's OK; could even make the dependencies in a sep doc

[ No objections ]

AB: next, Section 5 - Resolving DOM Nodes

Arve: we don't need to say anything about the URI scheme here
... I propose removing this section
... and be a bit more specific about how URIs are used where appropriate in the spec

AB: so you propose remove seciton 5?

Arve: yes

AB: any objections to that proposal?

[ None ]

AB: next is 7.3 - identifier attr
... "Issue: how does an author access the widget's id as declared in the config document? Also, what happens if this is not unique? How is uniqueness assured?

Arve: not sure what we should do here
... my proposal is to use an equivalent element in the config file and to use that

AB: any questions or concerns about that proposal?
... Marcos, what element would be used?

MC: not sure

AB: so the action for you Arve is to check the config file and come back with a proposal?

Arve: yes

<scribe> ACTION: Arve create a proposal for the A+E's section 7.3 Red Block issue re the identifier attribute [recorded in http://www.w3.org/2009/03/26-wam-minutes.html#action01]

<trackbot> Created ACTION-325 - Create a proposal for the A+E's section 7.3 Red Block issue re the identifier attribute [on Arve Bersvendsen - due 2009-04-02].

TR: is this just needed at runtime?
... is this put in the base URI
... want to understand what is needed for

Arve: we do not need to define how it is used
... at runtime, a unique id is generated
... and randomizes the base uri

TR: this seems like an simple detail
... want to understand how it is used by widget instance

MC: yes, what would a developer use it for?

TR: what is this attr used for?

<tlr> it might be that the attribute you really want is origin

TR: I don't think I'm getting an answer that substantiates its need

MC: yes, I agree with TLR

<tlr> but that's defined elsewhere ;)

Arve: perhaps you're right

BS: what about cross-widget comm?

MC: not sure we want to include it for that use Benoit

TR: I propose we remove identifier attribute

Arve: if wanted to use post message, could use this

<tlr> sure

AB: let's stop discussion and take this to the mail list

<tlr> AB: raise question in response to Arve's draft on the mailing list

<tlr> TR: sure

Arve: I will submit proposals for all of the Red Block issues starting with the one in Section 7.8

AB: that would be excellent Arve!

Window Modes spec

AB: what is the status and next steps?

<arve> anyone who wants to derive an origin url, could do so using document.domain

MC: we don't have any new status to report
... we need an editor

AB: do we have a skeleton doc?
... I mean anything checked into CVS?

MC: No

AB: any volunteers to drive this?

<tlr> arve, nooo

RB: I will take it!
... it may be about 10 days though before I can start working on it

AB: excellent Robin!

<fjh> fixes in widget signature complete, apart from latest comments received from Bondi and date of document

AB: any other hot topics
... Meeting Adjourned

Summary of Action Items

[NEW] ACTION: Arve create a proposal for the A+E's section 7.3 Red Block issue re the identifier attribute [recorded in http://www.w3.org/2009/03/26-wam-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/03/26 14:29:35 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/fixed it/will fix it/
Succeeded: s/<status>/<access>/
Succeeded: s/.AB/AB/
Succeeded: s/imple/simple/
Found ScribeNick: ArtB
Found Scribe: Art
Present: Art Thomas Frederick Mark Andy Robin Arve Marcos
Regrets: Jere Bryan
Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0926.html
Found Date: 26 Mar 2009
Guessing minutes URL: http://www.w3.org/2009/03/26-wam-minutes.html
People with action items: arve

[End of scribe.perl diagnostic output]