- 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:
<http://www.w3.org/2008/03/27-waf-minutes.html>
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]W3C
[1] http://www.w3.org/
- DRAFT -
Web Application Formats Working Group Teleconference
27 Mar 2008
[2]Agenda
[2] http://lists.w3.org/Archives/Member/member-appformats/
2008Mar/0012.html
See also: [3]IRC log
[3] http://www.w3.org/2008/03/27-waf-irc
Attendees
Present
Art, Arve, Claudio, Luca, Mike, Marcos, Ben
Regrets
Benoit
Chair
Art
Scribe
Art
Contents
* [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?
[None]
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?
[None]
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?
[None]
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
April
Issue #15
AB: [20]http://www.w3.org/2005/06/tracker/waf/issues/15
... P&C doc cover this:
[21]http://dev.w3.org/2006/waf/widgets/#embedding
[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
standardized
AB: does HTML5 have a registration system for rel attr values?
MS: yes there is one "of sorts"
<marcos>
[22]http://www.whatwg.org/specs/web-apps/current-work/#linkTypes
[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
registration
MS: agree; that mechanism is unlikely to survive as the HTML5 spec
progresses
ABe: there is no authoritative registry; standardization is done by
implementation
... 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
non-Normative
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?
[None]
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
soln
ABe: those attrs should be optional
AB: any concerns about adding these two attrs to the icon element?
[None]
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
not
... 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
duplication.
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
here...
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
domain
<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>
<java>yes|no</java></content>
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
model
... 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>
element
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?
[None]
RESOLUTION: plugins text clearly state that attribute is at risk
of removal
without clear and compelling UCs
AOB
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