See also: IRC log
Date: 8 August 2007
<scribe> Scribe: Art
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
AB: Section 4. Configuration document
ABe: I am concerned about the
name config.xml clashing with our engine
... I prefer manifest.xml
AB: I think we should name it Info.plist :-)
AvK: what about start.xml?
AB: widget.xml?
MC: that's been taken by Yahoo!
AB: any objections to manifest.xml? It isn't used by any of the Widget engines (AFAIK).
RESOLUTION: the configuration file shall be named "manifest.xml".
MC: the next issue is the
Namespace.
... currently the spec says http://www.w3.org/ns/widgets
AB: feedback already from the Public that a namespace is needed.
AvK: why?
MC: extensibility?
AvK: who would extend the syntax?
MC: vendors
AvK: but if only vendors are
going to extend it they can use whatever mechanism they
want
... they make authoring more complex
... If a vendor wants to extend it they can define their own
namespace or use vendor prefixing with element names e.g.
<opera-extension>
GG: if we remove the namespace we should say in the spec how to do extensions e.g. using prefixes for element names
AB: the public comment re namespaces is at: http://lists.w3.org/Archives/Public/public-appformats/2007Jul/0025.html
ABe: must also define some
mechanism to say that an element is mandatory i.e. if the
extended element is not present the engine should abort
... e.g. a mustUnderstand attribute
GG: I expect most if not all vendors to define their own JavaScript extensions
AvK: do we really need a mechanism to say that an extension element is mandatory?
GG: the requirement is the need to say that an extended feature is required for the widget to run
AvK: not sure I agree with this requirement
ABe: but I see a need for this requirement (some customers have asked for it)
GG: if you have this mechanism the UA can then post a message to the user saying something "but this Widget won't work because ...".
ISSUE: Widgets do we need to define a mechanism to state that an extension is mandatory?
RESOLUTION: the spec shall not define a namespace
<scribe> ACTION: Anne respond to Jason Monber'g Widget Namespace comment (http://lists.w3.org/Archives/Public/public-appformats/2007Jul/0025.html) [recorded in http://www.w3.org/2007/08/08-waf-minutes.html#action01]
<trackbot-ng> Created ACTION-106 - Respond to Jason Monber'g Widget Namespace comment (http://lists.w3.org/Archives/Public/public-appformats/2007Jul/0025.html) [on Anne van Kesteren - due 2007-08-15].
AB: Section 4.1. Microsyntaxes
ABe: should also state that "true" and "false" are valid values for boolean attributes
MC: what pattern is this following?
AvK: HTML5
... but I am OK with explicitly adding "true" and "false"
MC: OK. I will add text that states the syntax and semantics for "true" and "false"
AB: Section 4.1.2. Version list and identifier
ABe: my requirement is for a version string to be able to include both integers and letters (US-ASCII)
AB: is this algorithm copied from somewhere else?
AvK: no; I wrote it myself
MC: if letters are supported must define the collating/sorting semantics
AB: Anne, Arve can one of you update the algorithm to support letters and/or characters?
ABe: yes, I can do that
<scribe> ACTION: Anne work with Arve to update the version list algorithm to support letters and/or characters. [recorded in http://www.w3.org/2007/08/08-waf-minutes.html#action02]
<trackbot-ng> Created ACTION-107 - Work with Arve to update the version list algorithm to support letters and/or characters. [on Anne van Kesteren - due 2007-08-15].
AB: what is a valid identifier?
MC: it hasn't been defined
AB: what is the common pratice for identifies?
MC: only Dashboard seems to use it and they use reverse domain name e.g. com.apple.
ABe: Atom uses URIs
... for identifiers
... RFC 4287
... is there a specific requirement for Identifier?
MC: no, not really. The update requirement is a bit interlinked as the identifier is likely to used for updating.
GG: I think we should capture the Issue with a proposed solution of using a URI
Section 4.1.3. Language
ABe: why do we need language?
MC: I don't think we need it any more
AvK: I agree
AB: what was the intent?
MC: language negotiation. Perhaps we can consider it for v2.0
RESOLUTION: Language is to be dropped
Section 4.1.4. Links
AB: what is the Use Case or Requirement?
AvK: some type of intra packaging
linking mechanism
... need to define the mechism e.g. how to construct the
link
... for example need to know what '/' is relative to
AB: what needs to be done?
AvK: relatively easy task; need to check what is currently being done; see RFC3986
AB: Section 4.1.5. E-mail
ABe: email RFC is 2822
MC: we may need to include a Regular Expression
ABe: Atom points to one rule in
RFC2822
... the spec-address rule
MC: Web Forms 2 has some related text; we should copy it.
ABe: another option is to use the mailto: scheme i.e. RFC2368
MC: I will add the mailto option as a Note
AB: 4.1.6. Unsigned integers
ABe: without the word "only" in the first sentence the sentence is false
AB: is the first sentence sufficient?
MC: can I delete everything or is the algorithm needed?
AvK: we need it for width and height
AB: so the algorithm is needed for error handling e.g. to handle "1 45"?
AvK: yes
ABe: the integers are primarily
for width and height - could we use CSS length values instead
e.g. 100%?
... but CSS length values can have floating point
numbers
<scribe> ACTION: Anne re-write the non-negative Integer algorthim to be "tighter" [recorded in http://www.w3.org/2007/08/08-waf-minutes.html#action03]
<trackbot-ng> Created ACTION-108 - Re-write the non-negative Integer algorthim to be \"tighter\" [on Anne van Kesteren - due 2007-08-15].
MC: would it be possible to define a default for width and height?
GG: probably the only reasonable thing to do is to default to 100% x 100%
AB: if we had a default there wouldn't really be a need for the algortithm
ABe: I think width and height should be optional with some default values that are engine-dependent
AB: Section 4.2. The widget Element
AvK: want to add a "start" attribute and drop the <start> element
MC: OK, I'll make those changes
AB: what do we state about default width and height (it not specified or the value is in error)?
AvK: we could say that it is UA-dependent
AB: any objections to Anne's proposal?
RESOLUTION: if no width or height is specified or the specified values are in error then the default values are UA-dependent
ABe: we should look at Adobe Air
(http://labs.adobe.com/technologies/air/)
... does it make sense to provide controls over rendering of
window types
... wrt Accessibility need some type of Window controls
... need an attribute on the <widget> element for window
chrome
MC: like AIR's systemChrome
property?
... e.g. resizable, maximizable, etc.
<scribe> ACTION: Anne submit a proposal for the <widget> elements systemControls/chrome attribute [recorded in http://www.w3.org/2007/08/08-waf-minutes.html#action04]
<trackbot-ng> Created ACTION-109 - Submit a proposal for the <widget> elements systemControls/chrome attribute [on Anne van Kesteren - due 2007-08-15].
AB: Section 4.3. The title Element
AvK: the issue is that the
<title> element must specifiy its processing model e.g.
what shoud the UA do if the title element has
sub-elements
... same issue for th <description> element and others
with a "Text" content model
<scribe> ACTION: Marcos define the Processing Model for the Text elements e.g. title, desciption, author, licensing, etc. [recorded in http://www.w3.org/2007/08/08-waf-minutes.html#action05]
<trackbot-ng> Created ACTION-110 - Define the Processing Model for the Text elements e.g. title, desciption, author, licensing, etc. [on Marcos Caceres - due 2007-08-15].
AB: Section 4.4 Description
... any comments?
MC: I don't like the use of "short"
ABe: then remove it
MC: OK
AB: Section 4.5 author
Element
... Any comments?
ABe: suggest we copy what is done in ATOM spec
AvK: change href to url or link
AB: Section 4.6 license Element
ABe: why use "href" attribute name? I would prefer "url".
AB: seems like we should copy the most common practice
ABe: what does it mean if there is no licencse element at all or if the value is ""?
MC: I will add these issues to the Editor's Draft
AB: Section 4.7 icon Element
<anne> hey, our staff contact :)
<marcosc> yay!
<ChrisL> ok
MC: I support the DFAUI WG Note as is
AvK: I support the DFAUI WG Note as is
GG: I support the DFAUI WG Note as is
CL: I made some wording suggestions to Art but appart from that I'm OK with it.
http://lists.w3.org/Archives/Member/member-appformats/2007Aug/att-0001/DFAUI-WG-Note.html
<ChrisL> wgat about updating the xal link to one that works?
JC: 1st comment - usage of "stop"
in the Introduction is not applicable here
... stop is too strong here I think
CL: I don't think it shows a
judgement
... and is appropriate in this context.
JC: we do not want to close the door about this type of work at the W3C.
AB: the use of "its" qualifies the WAF WG
JC: OK.
... #2 - I have a problem with "lack of specification reuse".
Want the sentence to be dropped.
... IDEAL for example would reuse some existing specs.
CL: did not my change to "Concern over specification reuse" address your concern?
JC: there is no consensus on this statement
CL: but some members of the WG do
assert that statement
... my re-wording makes it clear some of the WG believe that
sentence
JC: the statement is not clear that some member think the Use Cases cannot be met by existing specs
<ChrisL> "Disagreement over the level and desirability of specification reuse"
How about two senteces:
1. Some members of the WG asserted the identified Use Cases and Requirements can be addressed by existing open standards (i.e. HTML4.01, CSS2.1, JavaScript, etc.) and/or by open standards in progress (i.e. HTML5, CSS3, XBL2, etc.)
2. Other members asserted the existing specifications cannot meet some of the Use Cases and Requirements.
<marcosc> MC: agrees with 1.
<marcosc> MC: agrees with 2.
<ChrisL> looks fine
JC: this is OK with me.
AB: any other concerns Jose?
JC: could add another Recommendation -> some of the Use Cases and Requirements identified could be addressed by the UWA WG's DIAL work.
<ChrisL> "dial could be extended to ..."
CL: DIAL could be extended to address some of the Use Cases and Requirements identified.
<ChrisL> fine by me
AB: any objections?
[NO objections raised]
<jcantera> Some members of the WAF Working Group believe that the development of open source implementations of DFAUIs (such as XAL, MyMobileWeb, OpenLaszlo, ...) might be a driver that will enable to resume the work on DFAUI in the W3C in the next couple of years in order to produce an open standard based on wide consensus.
<ChrisL> maybe after the bullet list in section 2 status
<ChrisL> i have no opinion either way on including it or not
<ChrisL> maybe reword recommendation bullet 1 - "After development of open source implementations of DFAUIs (such as XAL, MyMobileWeb, OpenLaszlo, ...), create a new DFAUI Working Group"
AB: Jose are you OK with Chris' rewording?
JC: yes
AB: any objections?
[no objections]
AB: any more comments Jose?
JC: none
AB: I propose we publish this
Note with the agreements we made today.
... any objections?
[NO objection]
<ChrisL> no objection
RESOLUTION: to publish this WG Note with the changes agreed on this call.
http://dev.nexaweb.com/home/us.dev/index.html@cid=1784.html
<cwei> Hey guys. I couldn't connect earlier. I'd like to talk about the note.
<jcantera> I think they are on a break
<Coach> ok.
Hi Coach. We started the DFAUI discussion at 15:00 local time as stated last week. We ended ~15:50.
The minutes are available here: http://www.w3.org/2007/08/08-waf-minutes.html
<Coach> I realize that - i couldn't connect earlier. The note has problems and need to be resolved.
Coach, we've moved onto a new topic.
<Coach> yes, understand. The subject of DFAUI has yet to be discussed and there are objections.
Coach, we are done with the DFAUI agenda item.
<Coach> I'd like to request to come back for another discussion at some other point of time because there are still unresolved issues.
<anne> We already decided to publish. You can make a formal objection to that I suppose by e-mailing to the mailing list if it's really important.
<anne> http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews
Coach, no we are done with DFAUI. We agreed to publish the Note with a few changes.
We have moved back to the Widgets spec.
AvK: someone proposed supporting multiple icons; I prefer to keep it simple, at least for now
<anne> To add to that, I kept it simple. It can be made more complex once a proposal comes to the table.
MC: I will make a note that
supporting mulitple icons is an open issue
... perhaps the <icon> element should have a title
attribute for Accessibility reasons.
ABe: is there a need to define icon states e.g. active, in-active, etc.?
MC: GIF89 means animated GIF
AvK: yes that's right
<Coach> The issues that i raised on email with you and chris being discussed in the minutes - which means that it is not resolved yet. You emailed that the agenda for DFAUI is allocated from 9-12 Boston time. I couldn't connect earlier but I am connected at 9:45. it is not right to say that the agenda item is done.
Coach, we finished the DFAUI discussion. We are not going back to it. Chris hung up after the discussion ended.
ABe: we need declarative access to the network (customer requirement)
GG: so we need some keyword pairs for various network resources
ABe: yes, something like that
MC: what does it mean to enable
the network?
... does it give cross-domain access?
... we do have the access control spec
ABe: I don't see that as relevant
MC: one problem for Widgets is
-> what is the origin?
... where the Widget was downloaded?
... what the Widget says is its origin?
... what does Flash do?
ABe: they follow the Same Origin Policy
MC: I can do some research into
what Flash does here.
... I think Widgets have a big cross domain access issue.
ABe: if an e-mail Widget gets
hijacked there could be serious side effects
... I think we should move this discussion to the mail list
GG: I agree; this is key issue particularly in the mobile space
<scribe> ACTION: Guido submit an input to the mail list regarding the Widget Security Model [recorded in http://www.w3.org/2007/08/08-waf-minutes.html#action06]
<trackbot-ng> Created ACTION-111 - Submit an input to the mail list regarding the Widget Security Model [on Guido Grassel - due 2007-08-15].
ACTION Anne - for Arve: Submit an input to the mail list regarding the Widget Security Model
<scribe> ACTION: Anne - for Arve: Submit an input to the mail list regarding the Widget Security Model [recorded in http://www.w3.org/2007/08/08-waf-minutes.html#action07]
<trackbot-ng> Created ACTION-112 - - for Arve: Submit an input to the mail list regarding the Widget Security Model [on Anne van Kesteren - due 2007-08-15].
AB: I propose we stop for the day. OK?
MC, AvK, ABe, GG: Yes, let's stop then.
AB: meeting adjourned until tomorrow.
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/to uri or/to url or/ Succeeded: s/reate/create/ Succeeded: s/back it/back to it/ Found Scribe: Art Found Scribe: Art Found ScribeNick: ArtB Default Present: +47.24.16.aaaa, jcantera, art, guido, marcosc, Chris Present: Art_(AB) Anne_(AvK) Guido_(GG) Marcos_(MC) Arve_(ABe) Agenda: http://lists.w3.org/Archives/Member/member-appformats/2007Jul/0020.html Found Date: 8 Aug 2007 Guessing minutes URL: http://www.w3.org/2007/08/08-waf-minutes.html People with action items: - an anne arve for guido input marcos respond submit with work[End of scribe.perl diagnostic output]