RE: [WARP] @required attribute on <access> element

Hi Marcos,

>>The P&C spec no longer says any such thing. The P&C is ignorant of  <access>.
I agree.
Thanks for finding the typo in my email.
I meant the following (it could be derived from the email, but the typo disturbed):

P&C spec says the following about @required on <feature>:
"    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."

Thanks.

Kind regards,
Marcin

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

-----Original Message-----
From: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres
Sent: Monday, July 27, 2009 6:33 PM
To: Marcin Hanclik
Cc: public-webapps@w3.org; public-device-apis@w3.org
Subject: Re: [WARP] @required attribute on <access> element

On Mon, Jul 20, 2009 at 6:41 PM, Marcin
Hanclik<Marcin.Hanclik@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 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.
>
>



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


________________________________________

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 Tuesday, 28 July 2009 10:02:04 UTC