Date: 8 August 2007

<scribe> Scribe: Art

<scribe> Scribe: Art

<scribe> ScribeNick: ArtB

Widgets 1.0 (continuation from yesterday)

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!

DFAUI WG Note

<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

Widgets spec Section 4.7. The icon Element

<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.

Section 4.9. The access Element

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