- From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Date: Mon, 20 Jul 2009 19:55:22 +0200
- To: "public-webapps@w3.org" <public-webapps@w3.org>
- CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Hi, Following my below email and given the semantic similarities (or equivalence) between: <access uri="http://example.org" subdomains="true"/> and <feature name="http://www.w3.org/widgetfeatures/networkaccess"> <param name="uri" value="http://example.org"/> <param name="subdomains" value="true"/> </feature> I am thinking whether the WARP spec could define the first feature based on P&C syntax? The @required attribute would be an issue then. If there is no agreement to the argumentation in my below email, then simply "http://www.w3.org/widgetfeatures/networkaccess" (or so) feature would be the one with predefinition @required="true" within WUA without the possibility for an override. This in turn would be a willfull violation (really?) of the following sentence: "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." from http://dev.w3.org/2006/waf/widgets/#the-feature-element. Thanks. Kind regards, Marcin ________________________________________ From: public-device-apis-request@w3.org [public-device-apis-request@w3.org] On Behalf Of Marcin Hanclik [Marcin.Hanclik@access-company.com] Sent: Monday, July 20, 2009 6:41 PM To: public-webapps@w3.org Cc: public-device-apis@w3.org Subject: [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. ________________________________________ 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 17:56:17 UTC