W3C home > Mailing lists > Public > public-appformats@w3.org > March 2008

[widgets] Minutes from 27 March 2008 Widgets Voice Conference

From: Arthur Barstow <art.barstow@nokia.com>
Date: Thu, 27 Mar 2008 08:23:49 -0400
To: public-appformats@w3.org
Message-Id: <90586FCF-957A-4FE7-9D19-06BF850FFA00@nokia.com>
All - The minutes from the WAF WG's March 27 VoiceConf on Widgets are  
available at the following and copied below:


WG Members - if you have any comments, corrections, etc., please  
send  them to the public-appformats mail list before April 2;  
otherwise the minutes will be considered approved.

-Regards, Art Barstow


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

                                - DRAFT -

          Web Application Formats Working Group Teleconference
                               27 Mar 2008


       [2] http://lists.w3.org/Archives/Member/member-appformats/ 

    See also: [3]IRC log

       [3] http://www.w3.org/2008/03/27-waf-irc


           Art, Arve, Claudio, Luca, Mike, Marcos, Ben





      * [4]Topics
          1. [5]Agenda Review
          2. [6]Charter Update
          3. [7]Issue #13
          4. [8]Issue #14
          5. [9]Issue #15
          6. [10]Charter Redux
          7. [11]Issue #15
          8. [12]P&C section 6.9
          9. [13]Icon element
         10. [14]Content Type Signatures
         11. [15]Access Element
         12. [16]AOB
      * [17]Summary of Action Items

    <trackbot-ng> Date: 27 March 2008

    <scribe> Scribe: Art

Agenda Review

    AB: change requests?


Charter Update

    AB: Mike, charter update please?

    MS: some progress being made but I can't give an estimate about how
    much more time it will take
    ... I will try to talk to Doug offline and maybe give some details
    at the end of this call

Issue #13

    AB: [18]http://www.w3.org/2005/06/tracker/waf/issues/13

      [18] http://www.w3.org/2005/06/tracker/waf/issues/13

    MC: there are two parts
    ... 1. extension via a namespace
    ... 2. there was a request for an extensions folder
    ... I responded already: #1 - of course that can be done
    ... regarding #2: the spec doesn't preclude it but I don't think we
    should standardize it

    AB: any questions/concerns about Marcos' answers and responses?

    MC: I think it should be closed

    ABe: agree

    AB: propose we close it; any objections?


Issue #14

    AB: [19]http://www.w3.org/2005/06/tracker/waf/issues/14

      [19] http://www.w3.org/2005/06/tracker/waf/issues/14

    MC: we agreed to use a URI

    AB: yes via the widget element's id attribute

    MC: we have not verified what happens if the URI is not valid (in
    the ProcMod)

    ABe: would you elaborate?

    MC: what if its an arbitrary string?
    ... what does the widget engine do?

    ABe: in our engine we just auto-generate one

    MC: there are two ids in practice: an internal one used by the
    engine; a public id

    AB: propose we close the issue; any objections?


Issue #15

    <Zakim> MikeSmith, you wanted to talk about WebApps charter progress

Charter Redux

    MS: the Team review is completed; we expect the proposal to go to
    the AC review soonish, hopefully next week

    MC: any details Mike?

    MS: no, I can't do that

    AB: how many WGs?

    MS: plan is to be just one WG
    ... hope to have the charter approved by the Director by the end of

Issue #15

    AB: [20]http://www.w3.org/2005/06/tracker/waf/issues/15
    ... P&C doc cover this:

      [20] http://www.w3.org/2005/06/tracker/waf/issues/15
      [21] http://dev.w3.org/2006/waf/widgets/#embedding

    MC: can use the link element and the rel attribute
    ... the question is whether or not the rel attr value can/should be

    AB: does HTML5 have a registration system for rel attr values?

    MS: yes there is one "of sorts"


      [22] http://www.whatwg.org/specs/web-apps/current-work/#linkTypes

    MS: it's a bit of a hack
    ... if you want a new rel attr, you go to a WHAT WG wiki and add it
    ... not very robust
    ... e.g. validation is problematic
    ... I think something more formal is needed.

    ABe: that process is just too ad-hoc
    ... kinda' like the microformats community's way of handling

    MS: agree; that mechanism is unlikely to survive as the HTML5 spec

    ABe: there is no authoritative registry; standardization is done by
    ... perhaps we should drop it

    MC: the current text is Informative

    AB: that's not clear i.e. Normative versus non-Normative

    <marcos> The text: [23]http://dev.w3.org/2006/waf/widgets/#embedding

      [23] http://dev.w3.org/2006/waf/widgets/#embedding

    MC: we need a decision

    AB: I don't think we should build a dependency on HTML5
    ... I'm OK with current text but it should be clearly marked as

    ABe: if we have nothing Normative to point to then just marking it
    non-Normative is OK
    ... we could also remove it

    MC: we can mark it non-Norm now and then remove it later if
    data/feedback suggest so

    CV: if we remove it then we wouldn't provide any info on how to
    discover, right?

    MC: right

    ABe: this is about some UA provide an interface with data to tell
    the user about a Widget

    MC: there can also be some security issues with this

    AB: propose we leave text in but clearly mark it as non-Normative

    MS: we could also mark this section as "needs to be visited"

    AB: any objections to my proposal?


P&C section 6.9

    AB: [24]http://dev.w3.org/2006/waf/widgets/

      [24] http://dev.w3.org/2006/waf/widgets/

    MC: I change title element to name to match existing engines

    <marcos> [25]http://dev.w3.org/2006/waf/widgets/Overview.src.html

      [25] http://dev.w3.org/2006/waf/widgets/Overview.src.html

Icon element

    ABe: we support more than one icon element
    ... and have requirements to do so

    MC: how do you differentiate between them

    ABe: we have a width and height attr for them

    MC: that's what I proposed on the mail list; think its a practical

    ABe: those attrs should be optional

    AB: any concerns about adding these two attrs to the icon element?


    MC: I don't like the role attr and think width and height are better
    ... for example "big", "small" for the icons
    ... think it is confusion

    ABe: in the ideal world, role would probably work; but not clear
    it's useful e.g. in the mobile world

    MC: I would like a resolution on this; want optional width and
    height and unbound number of icon elements

    AB: any comments on MC's proposal?
    ... any objections to MC's proposal?

    RESOLUTION: the icon element will have width and height attributes
    and can have >= 0 icon elements

    <marcos> MC: I've added "Content Type Signatures"

    <marcos> MC: from HTML5

Content Type Signatures

    MC: I've added Content Type Signatures; text from HTML5

    AB: have these algorithms been implemented by the major UAs?

    MC: yes

    AB: any other changes?

    MC: I updated the Relax NG schema

Access Element

    MC: basically says whether the widget needs to access the network or
    ... this is consistent with existing engines e.g. Dashboard, Opera
    Widgets (IIRC)

    ABe: we will be making some small changes to our implementation
    ... e.g. can limit it to one domain

    <tlr> marcos, about "content type signatures" -- I can only guess
    what this means, but "text from HTML5" sounds like a recipe for spec

    ABe: our new model is to opt-in

    <arve> <widget network="private public">

    <marcos> tlr, true... I only added zip signature...

    <tlr> pointer to the access element?

    ABe: our new model will be to opt-in

    <marcos> tlr,
    [26]http://dev.w3.org/2006/waf/widgets/Overview.src.html search for
    access element

      [26] http://dev.w3.org/2006/waf/widgets/Overview.src.html

    <tlr> thx, found it

    ABe: we need to add flexibility on which networks are supported

    <tlr> I don't think there's a useful "public / private" distinction

    MC: I'd like to see the latest proposal

    ABe: yes, I'll need to get you a sanitized version
    ... we need more than just "yes" or "no"
    ... currently it is not possible for a widget to lock down its

    <marcos> MC: need some kind of <origin> ?

    AB: the security model section was removed, right?

    MC: correct
    ... there needs to be some text about the Sec Model; it could be in
    the P&C spec or a separate spec

    AB: what is the status on the Security Model input, Arve?

    ABe: I need to remove some internal impl details before I can
    release it to the WG
    ... hopefully I can get it published soon; perhaps within one week

    MC: excellent!

    AB: +
    ... any comments about the plugins attribute?

    MC: I'm uncomfortable with this as specified because I don't know
    what the UA will actually do with it?
    ... e.g. need to formally define a plugin

    <tlr> (As a side note, access sounds like it would better have child
    elements, not attributes for the individual things.)

    MC: not clear what "no" would mean as well as "yes"
    ... is Flash a plugin in this context?
    ... or an SVG viewer?

    AB: whose is implementing this now?

    MC: Opera; Dashboard has something like it

    AB: do they address the proc model issues you are raising?

    MC: no, not really

    AB: could identify it as a feature at risk of removal without clear
    UCs to support it

    <marcos> MC: dashboard says <key>Allow Java</key>

    AB: that is a True/False

    <marcos> MC :Optional. Boolean value. Allow the inclusion and
    execution of <applet> elements.

    <marcos> MC: complimented by <key>AllowFullAccess</key>

    <marcos> Optional. Boolean value. Gives full access to file system,
    Web Kit and standard browser plugins, java, network, and
    command-line utils.

    <marcos> MC: opera uses content><plugins>yes|no</plugins>

    AB: do we need the plugins attr for v1 of the P&C spec?

    ABe: agree there are some issue e.g. formall definition of a plugin
    ... also some potential security issues with the plugins' security
    ... not sure it is relevant

    MC: this really muddies the water WRT interop

    AB: perhaps we should add some text that it will removed if there
    are no compelling UCs

    MC: I'm ok with that

    AB: we could also just delete it

    MC: I'm OK with that too but need to hear from Arve

    ABe: the UCs for keeping it are a bit weak
    ... my proposal is that we think of "extended security component" or
    some such stuff

    MC: maybe this is beyond the scope of this work
    ... HTML 5 guys are going to have similar probs e.g. <applet>

    ABe: I support the proposal of marking it as risk

    CV: we don't have a resolution for the network attr; we think it
    should be "richer"
    ... we have some UCs for that

    AB: propose that the plugins text clearly state that attribute is at
    risk of removal without clear and compelling UCs
    ... any objections?


    RESOLUTION: plugins text clearly state that attribute is at risk  
of removal
    without clear and compelling UCs


    AB: any hot topics?

    MC: lots of updates to the Landscape and Signatures doc

    AB: excellent
    ... Meeting Adjourned

Summary of Action Items

    [End of minutes]

Received on Thursday, 27 March 2008 12:25:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:22 UTC