Re: [widgets] [access] Naming Conflict: Element

HI Doug, On Fri, Feb 20, 2009 at 2:44 AM, Doug Schepers wrote: > Hi, WebApps WG and XHTML2 WG- > > There is a potential conflict between the element defined in > the Widgets 1.0: Packaging and Configuration specification [1] and the > element defined in the XHTML Access Module specification [2]

ISSUE-82 (Access element naming conflict): potential conflict between the XHTML and Widget element [Widgets]

ISSUE-82 (Access element naming conflict): potential conflict between the XHTML and Widget element [Widgets] http://www.w3.org/2008/webapps/track/issues/82 Raised by: Doug Schepers On product: Widgets In [4], Doug Schepers identified a potential conflict between the element defined in the

Re: [widgets] [access] Naming Conflict: Element

Hi, Robert- Robert Sayre wrote (on 2/20/09 12:56 PM): > On Thu, Feb 19, 2009 at 8:44 PM, Doug Schepers wrote: >> >> Thoughts? > > Believe in namespaces or don't. Oh, I believe in namespaces. But when it can be avoided, it's better for authors if: a) there are as few duplicate names for dissim

Re: [widgets] [access] Naming Conflict: Element

The access element in XHTML Access Module [1] is not a key navigation element - it is a method for defining an abstract mapping from events to event handlers[2]. One such event might be a key press. The XHTML Access Module has been under development for ages, and that name was specifically ch

Re: [widgets] [access] Naming Conflict: Element

On Thu, Feb 19, 2009 at 8:44 PM, Doug Schepers wrote: > > Thoughts? Believe in namespaces or don't. -- Robert Sayre "I would have written a shorter letter, but I did not have the time."

[widgets] [access] Naming Conflict: Element

Hi, WebApps WG and XHTML2 WG- There is a potential conflict between the element defined in the Widgets 1.0: Packaging and Configuration specification [1] and the element defined in the XHTML Access Module specification [2] (most recent draft also available [3]). It may be that both are never us

Re: [selectors-api] Stringifying undefined

The test suite has been updated accordingly: http://ejohn.org/apps/selectortest/ http://github.com/jeresig/selectortest/commit/4827dedddaea6fa0b70cfdaadeeafef0d732a753 --John On Thu, Feb 19, 2009 at 6:40 AM, Lachlan Hunt wrote: > Jonas Sicking wrote: >> >> On Wed, Feb 18, 2009 at 7:34 AM, Ann

[widgets] The access element (was: RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec)

Hi All, In the email [1] containing my comments against the LCWD of Widgets 1.0: Packaging & Configuration spec, I wrote: >> 7.10 The access Element >> The access element defines a network attribute as "A boolean attribute >> that indicates that the widget might need to access network resources

[widgets] Action #224 - Work with Marcos to flesh out the details of the processing model for multiple signatures

Hi All, In response to: Action #224 - Work with Marcos to flesh out the details of the processing model for multiple signatures; Mark and Marcos - http://www.w3.org/2008/webapps/track/actions/224 I have outlined two alternative approaches to a

Re: [widgets] Declarative support for a widget's metadata

On Thu, Feb 19, 2009 at 6:47 PM, Arthur Barstow wrote: > Marcos, > > A few weeks ago we talked about how a widget author could add > widget-specific metadata (e.g. initial settings) to the config file [1]. > > I think providing a declarative means to provide this metadata is consistent > with exis

[widgets] Declarative support for a widget's metadata

Marcos, A few weeks ago we talked about how a widget author could add widget- specific metadata (e.g. initial settings) to the config file [1]. I think providing a declarative means to provide this metadata is consistent with existing Req #14 - Widget Metadata [2]. Additionally, at least s

Re: Using different widget signature roles

Attached is comment I sent on Mark's notes: --- Mark yes I think this is appropriate. I would suggest that the processing rules for signature verification be uniform, apart from the fact that a distributor signature includes author signature Reference. Then I would argue it is application d

[widgets] Minutes from 19 February 2009 Voice Conference

The minutes from the February 19 Widgets voice conference are available at the following and copied below: WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 5 March 2009 (the nex

[widgets] Digital Signature Roles - summary of proposal

Hi All, Below is a copy of the proposal that I sent to Frederick and Marcos following last week's WebApp call to capture the agreements that were reached in regards to defining different signature roles. I'm reposting to the public list to provide background to the updates to that Widgets 1.0:

[widgets] A revised proposal on widget modes

Hi All, Based on some of the emails that have followed our initial proposal for widget modes [1] we have come up with a revised proposal for discussion. I have focused this solely on what would need to go into the packaging and configuration specification [2], ie there is no real mention of how v

RE: If not Multiple-Contents, how do we have Widgets with multiple modes?

Hi Ivan, Marcos, All, Some specific comments inline, marked [mp]. I will send out a separate email outlining a proposal that we believe meets the requirement around modes. A more general comment - from Ivan's email, a requirement I would add to the list I communicated in [1] is: "A widget MUST b

Re: [selectors-api] Stringifying undefined

Jonas Sicking wrote: On Wed, Feb 18, 2009 at 7:34 AM, Anne van Kesteren wrote: So ideally what we do here is simply in line with how we plan to make all APIs that accept strings work (with exceptions). Yup, that's exactly what I've been arguing (both for this and for other APIs). I think we s

RE: [widgets] Agenda for 19 February 2009 Voice Conference

Hi Art, >c. Action #275 - What is our lifecycle, revocation model?; Mark > http://www.w3.org/2008/webapps/track/actions/275 I think this action can be closed - I believe we have agreed that the Widget 1.0: Digital Signatures spec will only cover the format, generation and processing of a digita