[widgets] Minutes from 26 March 2009 Voice Conference

The minutes from the March 26 Widgets voice conference are available
at the following and copied below:


WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before 2 April 2009 (the next
Widgets voice conference); otherwise these minutes will be considered

-Regards, Art Barstow


       [1] http://www.w3.org/

                                - DRAFT -

                        Widgets Voice Conference

26 Mar 2009


       [2] http://lists.w3.org/Archives/Public/public-webapps/ 

    See also: [3]IRC log

       [3] http://www.w3.org/2009/03/26-wam-irc


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

           Jere, Bryan




      * [4]Topics
          1. [5]Review and tweak agenda
          2. [6]Announcements
          3. [7]DigSig
          4. [8]P&C spec: L10N model
          5. [9]P&C spec: status of <access> element:
          6. [10]P&C spec: <update> element given Apple's patent
          7. [11]P&C spec: step 7 - need to add <preference> element and
             the <screenshot> element;
          8. [12]P&C spec: XML Base
          9. [13]A&E spec
         10. [14]Window Modes spec
      * [15]Summary of Action Items

    <scribe> ScribeNick: ArtB

    <scribe> Scribe: Art

    Date: 26 March 2009

Review and tweak agenda

    AB: I posted the agenda on March 25
    26.html Note DigSig is not on today's agenda.
    ... Are there any change requests?

      [16] http://lists.w3.org/Archives/Public/public-webapps/ 

    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> [17]http://www.w3.org/2005/07/13-nsuri

      [17] 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:
    ... 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?

      [18] http://lists.w3.org/Archi

    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.
    [19]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?

      [19] http://dev.w3.org/2006/waf/widgets/#the-access-element

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

    <Marcos> I need to align it with

      [20] http://homer.w3.org/~connolly/projects/urlp/raw-file/ 

    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

    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. [21]http://*.googlemaps.com

      [21] 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)
    [22]http://dev.w3.org/2006/waf/widgets/#the-update-element and Step
    ... 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?

      [22] http://dev.w3.org/2006/waf/widgets/#the-update-element
      [23] http://dev.w3.org/2006/waf/widgets/#step-7-process-the- 

    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?

      [24] http://dev.w3.org/2006/waf/widgets/#step-7-process-the- 

    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

P&C spec: XML Base

    AB: Thomas and Marcos have exchanged some emails about this
    83.html What is the status and what specifically needs to be done to
    address the issue?

      [25] http://lists.w3.org/Archives/Public/public-webapps/ 

    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:

      [26] 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

    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


      [27] 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

    <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

    <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

    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

    [End of minutes]

Received on Thursday, 26 March 2009 15:48:48 UTC