On Mon, Jul 20, 2009 at 6:41 PM, Marcin Hanclik<marcin.hanc...@access-company.com> wrote: > 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. >
The P&C spec no longer says any such thing. The P&C is ignorant of <access>. > 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 acc...@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 feat...@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 acc...@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.hanc...@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. > > -- Marcos Caceres http://datadriven.com.au
