Re: [WARP] Call for comments on pre-LC#2 of WARP spec; deadline 18 November

Hi Suresh,
Thanks for the feedback; some comments and questions below...

On Wed, Nov 18, 2009 at 11:11 PM, Suresh Chitturi <schitturi@rim.com> wrote:
> Hello Art, all,
>
> Please find below a comment that we would like to submit to towards the
> following WARP Editor's draft.
>  http://dev.w3.org/2006/waf/widgets-access/
>
> If you recall, I did raise the same comment at the joint F2F meeting
> between Widgets and DAP WG during TP week, and it was recommended that I
> submit it formally before the deadline.
>
> ISSUE: The <access> element does not specify the ability to have nested
> <feature> elements.

This is not really an "issue". An issue would be something like "The
access element does not handle scenarios x, y, and z; therefore,
access is broken."

> RATIONALE: The ability of having nested <feature> elements under the
> <access> element, allows the widget authors to control access to a
> specific set of (platform) features on a per resource/domain basis,
> improving the overall access-control and Widgets security model.

Can you describe the use cases here? I know for playing around with
the blackberry emulator that you guys (RIM) already implement this.
Can you give us some insight into the actual use case and rationale?
What kinds of features are being tightly controlled by <access>?

> PROPOSED RESOLUTION: Specify the use of zero or more <feature> elements
> as a child of <access> element. This will require that the current
> specification of <feature> element in Widgets 1.0 is reworded to say
> that it could be present either as a child of <widget> element or
> <access> element.
> However, in the spirit of having no impact to the
> Widgets P&C 1.0 specification, an alternate approach would be to add a
> new element called <accessFeature> (or similar) that uses the same
> syntax and semantics of the <feature> element. An <access> element
> thereby, may contain a zero or more <accessFeature> elements under it to
> indicate the features that the subject resource/origin/domain in the
> <access> element is entitled or has access to during the Widget
> execution.
>
> This, we believe will not only offer a fine-grain access control to
> specific features on a per-domain basis but can also be benefit
> implementations to load only those feature "modules" into the JavaScript
> context that are declared by the widget authors on a per-domain basis.

As WARP defines it's own processing model, so any additions can just
be defined there.

-- 
Marcos Caceres
http://datadriven.com.au

Received on Thursday, 19 November 2009 11:04:35 UTC