See also: IRC log
<trackbot-ng> Date: 27 March 2008
<scribe> Scribe: Art
AB: change requests?
[None]
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
AB: 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]
AB: 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]
<Zakim> MikeSmith, you wanted to talk about WebApps charter progress
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
AB: http://www.w3.org/2005/06/tracker/waf/issues/15
... P&C doc cover this: 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> 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: 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]
AB: http://dev.w3.org/2006/waf/widgets/
MC: I change title element to name to match existing engines
<marcos> http://dev.w3.org/2006/waf/widgets/Overview.src.html
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
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
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, http://dev.w3.org/2006/waf/widgets/Overview.src.html search for access element
<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: Content
Type Signatures
... 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
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) No ScribeNick specified. Guessing ScribeNick: ArtB Found Scribe: Art Present: Art Arve Claudio Luca Mike Marcos Ben Regrets: Benoit Agenda: http://lists.w3.org/Archives/Member/member-appformats/2008Mar/0012.html Found Date: 27 Mar 2008 Guessing minutes URL: http://www.w3.org/2008/03/27-waf-minutes.html People with action items:[End of scribe.perl diagnostic output]