[WARP] @required attribute on <access> element

Dear All,

Following the discussions (as below) about the topic of the required attribute on <access> element, I would like to provide a few comments to the current WARP WD.

Historically <access> element was earlier in the widget set of specification than <feature>.
>From the design perspective the network access is a feature as are any other potential features (not specified in W3C yet, but coming in DAP), like messaging (SMS, MMS, any other means), file access etc.
The semantic difference between <access> and <feature> is the missing @required attribute on <access> element.

Removing from the below notes the following comments:
- UX aspects, since they are the same as for feature
- Policy aspects, for the same reason
we could conclude that indeed @required could be put onto <access> element to uniformly treat functionalities/features and to prepare a consistent model - within all the widgets specifications - for any discussions around security policies in DAP. It seems that DAP may bring new inputs to the discussion about @required attribute, I just think that we may discuss it sooner so that the WARP spec ensures the consistency of the widget packaging data model.

If possible, I would like to start a discussion about this topic over email, since the discussion during F2F (as below) seems to have diverted into undesired direction leaving the topic actually not fully clarified (either for or against).

Following reasoning provided by Bryan Sullivan (e.g. http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0489.html), my use case for @required attribute is as follows:
Imagine a widget that is fully functional without network, e.g. an off-line game or MMS/SMS-client widget.
The widget requires the network access only in very specific cases, e.g. to upload game result, and network access can easily fail, it is not mandatory for the normal operation of the widget.
If the device/WUA has a policy specified (assuming W3C will define some, or e.g. as it is done within BONDI), the authority defining the policy may be interested in controlling the network access, due to e.g. roaming, similarly to controlling any other feature.

The WARP spec says:
"For example, when a user attempts to install a Widget in a User Agent, and the Widget Configuration Document declares that it requires access to currently blocked services in order to function, the User Agent may prompt the user to choose to:

   1. enable access to the service (for example, adding the service to a proxy server or firewall white list),
   2. cancel installing the Widget, or
   3. proceed with installation, with the user now aware that there may be problems with the Widget due to restricted access to services."
Adding @required on <access> would change the state-machine related to widget.
Currently if a widget requires network access, it is assumed that this access would be granted once forever, at installation time. It defaults to having @required="true".
@required="false" would mean - as for the above use case - that the widget does not have to access the network, it just may request such access.

P&C spec says the following about @required on <access>:
"    When set to true, the required attribute denotes that a feature is absolutely needed by the widget to function correctly, and without the availability of this feature the widget serves no useful purpose or won't execute properly.
    When set to false, the required attribute denotes that a widget can function correctly without the feature being supported or otherwise made available by the user agent.
    The default value that a user agent must use when the required attribute is absent is true, meaning that the feature must be made available to the widget by the user agent at runtime.
    It is optional for authors to use the required attribute with an feature element."

The intended semantics of the @required attribute on <access> would be exactly the same as in P&C, thus there is potential for having a consistency.

To sum up, the most important argument for @required on <access> is the consistency of the model for <feature> and <access> elements.

Thanks.

Kind regards,
Marcin

Robin
>>I'm happy to add a required attribute with the same semantics
>>and processing as those of the same attribute on
>><feature>. I think it makes sense to be consistent here.

Marcos
>>I can live with this if the rest of the WG wants it,
>>but I don't get the sense this will get used much (i.e., required = "false').
>>So again, do we _REALLY_ need this?

Bryan
>>In the case of the resources identified by <access>, widgets may be designed to use a variety of them.
>>As close to a specific example I can give (recognize that I expect the variety of widgets
>>and their relationships to content/service resources to be much wider) is:
>>- a social networking widget is designed to use the HTTP-based API's provided by various
>>social network providers, and includes the API URI's in <access> elements
>>- some of these resources may not be accessible due to policies in effect
>>for the user and/or service provider
>>- the widget is nonetheless designed to work with some of the social networks
>>via an alternate resource, e.g. an API proxy provider, which is allowed per policy
>>- the widget is thus usable on devices in which at least the API proxy resource
>>is accessible: thus it is "required", and the others "optional"
>>
>>There are various valid reasons (validity of course here being in the eye of the user
>>and/or service provider) for variation in resource accessibility,
>>and these can be expressed as policies e.g. via BONDI, which can be used
>>in the compatibility decision process. With the complimentary expression of *need*
>>in the <access> element, we can support a complete system of compatibility verification,
>>without widget-package-external metadata (e.g. something maintained in a proprietary way
>>as part of an app store widget cataloging system).

http://www.w3.org/2009/06/09-wam-minutes.html
BS: it had to do generally with the purpose for the access element v the feature element
... there were two things I proposed
... 1) a @required flag
... you get only what you declare in the way it is defined, which means that without prior knowledge that a specific domain is going to be allowed, you won't find out until it doesn't work
... you can't get access to things that may be useful but not essential
... <feature> was designed around that, but not <access> - which I find is similar in nature
... you could have alternate approaches if a netres is not available
... I based access@required on the feature
RB: it's commented out, pushed out to v2
BS: why defer?
AB: I think the general reason why some of us felt we should put it off is because we hit LC around christmas last year, and we'd like to consider ourselves feature-complete
BS: but WARP has been moved out into a separate spec
BS: is it assumed WARP is near LC?
AB: when we made that decision, it was still in PC
... so does the decision move with it?
AB: the idea was that WARP should move at warp speed
... I suggest that the same rationale applies
... we don't want any new features
MC: I still don't see much use for these attributes, so from Opera's point of view we don't see them as that useful
JK: I'm indifferent about @required, but @duration is disconcerting
... I see a lot of echo of J2ME and the result of that is when these values were used and applied to mutiple different APIs it very quickly turns into excessive prompting
JK: that's a UX killer - if we bring that into <access> where the granularity is a URL, and you have several of these, you're going to get more prompting, and a dreadful UX
RT: I agree, you're implying UX with prompting - we don't want to imply UX, that's an implementation thing
MH: consolidation of the prompts?
MH: this is an important factor
BS: the purpose is not to mandate a UI/UX
... obviously apps have to be designed or vetted to access some features
<ArtB> Bryan's email: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/att-0844/00-part
BS: the purpose of this disclosure is not to promote a given security model
BS: we will eventually have a process of alignement
BS: we see this process of prompting as essential
BS: but this is just like feature@required
... this is about what the widget needs to be able to do
MC: even if @required is going to be useless because the URL might be unavailable
BS: but you can still have a policy
MC: yeah, but I think it's overkill
... <access> says what you want to access, and then it might but unavailable
... so you're already handling that case
BS: but the widget won't install
RB: we don't say whether the widget gets installed or not
MC: you know access@uri
... if it's not allowed to access something inside the range of URIs, the required doesn't change anything there
... on feature it's different but I could live with dropping it there
errrrr
sorry, had to undrop it
MC: the request would just fail
BS: but with @reuiqred you can check that by policy
... you could implement APIs on the web represented as URIs much more flexibly, but they should be equal citizen with feature
MC: required on feature is a legacy from when we had fallback - this has gone so it could go too
RB: if we drop @required on feature we have to go back to LC
BS: if you discover incompatibility earlier, you have a better UX
Josh: wrong, users get pissed because they can't install the widget that their friend has
... if it bails out too early I can't use it
... I can show examples of this
BS: I would prefer to not even offer that to download based on capability
... we can do this in PC, or we can do this externally
MC: why do we assume that there will be different policies for different devices
BS: we do policy per context, in MIDP and native
MC: which are very unsuccessful
BS: some people chage, some people don't
AB: the more we talk about policy, the more I think it's a DAP problem
RB: thank you Art, you'll pay for that
<JereK> +1
AB: I'm not hearing a lot of support within this WG to do it here
... there's an opportunity to submit furhter comments when FPWD is out
... WARP isn't in LC, so in theory it's open to features
emphasis on theory
AB: I recommend ending the discussion now, and discussing when the FPWD is out
MC: in the future, there's only ever going to be one policy
... for all devices
RB: developers certainly would prefer that
RESOLUTION: Policy gets discussed in DAP
MC: we can add it in a separate spec
BS: we'd like to avoid the overhead of addiotinal spec
Josh: we'd like to avoid the overhead of extra attributes that turn out to be useless
the WG opens a bet about the future
ADJOURNED


Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Monday, 20 July 2009 16:43:02 UTC