Hi Suresh,
Thanks for the feedback; some comments and questions below...
On Wed, Nov 18, 2009 at 11:11 PM, Suresh Chitturi schitt...@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 PC 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
