RE: [WARP] Last Call comments (1)

Hi Marcos,

>>What you did in 192 characters, the access element does in 52.
>>
>>That is the point of the access element: to make these kind of
>>annoying declarations easy to write.

I do not think that the conciseness is the main driver of this aspect of the config.xml.
What matters seems to be semantics, specifically in the light of the security model and selectiveness of the intentions.

The size of the expression could be lowered a bit, e.g. the IRI could be changed from;
http://www.w3.org/widgetfeatures/networkaccess/http

to
http://www.w3.org/wf10/na/http

and so on.

From another angle:
We seem to agree to have implicit API versioning (in DAP) that result in multiplication of the size of the runtime code (note the performance impact), so having a few more characters in config.xml with clearly defined semantics seems not to be an issue, I think.

Thanks,
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: Friday, September 04, 2009 5:04 PM
To: Marcin Hanclik
Cc: public-webapps@w3.org
Subject: Re: [WARP] Last Call comments (1)

Hi Marcin,
I tried to respond to this email, but in all honesty, I can't follow
your line of argumentation. Maybe you can list your main points as a
list (sorry, I'm a bit simple)...

From what I got, I agree that WARP is over reaching: It does not
address the requirements it lists from the Widgets 1.0: Requirements
document. Otherwise, I'll just leave it to Robin to respond.

I've made some notes on the proposed changes.

On Thu, Aug 27, 2009 at 8:06 PM, Marcin
Hanclik<Marcin.Hanclik@access-company.com> wrote:

> PROPOSED CHANGES
>
> Given the semantic similarities (or equivalence) between:
>
> <access uri="http://example.org" subdomains="true"/>
>
> and e.g.:
>
> <feature name="http://www.w3.org/widgetfeatures/networkaccess/http" required="false">
>    <param name="uri" value="http://example.org"/>
>    <param name="subdomains" value="true"/> </feature>


What you did in 192 characters, the access element does in 52.

That is the point of the access element: to make these kind of
annoying declarations easy to write.

> I propose the following:
>
> 1. Change the name of the specification to "Widgets 1.0: Network Access Feature" and focus on per-URI-scheme definition of the syntax dependencies and functionality.
>
> Examples:
> a)
> The following feature could replace the generic network access (proposed in the LCWD as "*" for @uri attribute):
>
> <feature name="http://www.w3.org/widgetfeatures/networkaccess" required="true" />
>
> b)
> The following features could define the http and https access
>
> <feature name="http://www.w3.org/widgetfeatures/networkaccess/http" required="false">
>    <param name="uri" value="http://example.org"/>
>    <param name="subdomains" value="true"/>
>    <param name="ports" value="80, 8080"/> </feature>
>
> <feature name="http://www.w3.org/widgetfeatures/networkaccess/https" required="true">
>    <param name="uri" value="https://example.org"/>
>    <param name="subdomains" value="false"/>
>    <param name="interface" value="XMLHttpRequest"/>
>    <!-- port defaults to 443 -->
> </feature>
>
> c)
> The following feature could define access to SMS feature:
>
> <feature name="http://www.w3.org/widgetfeatures/networkaccess/sms" required="true">
>    <param name="uri" value="sms:+16177166200"/> </feature>
>
> <feature name="http://www.w3.org/widgetfeatures/networkaccess/sms" required="true">
>    <param name="countrycallingcodes" value="1,48,49,34"/> </feature>
>
> 2. Rewrite parts of the specification - specifically section 3, while keeping its majority as is - to adhere to the syntax of the <feature> and <param> elements as outlined above.
>
> 3. Refrain from specifying the default policy; remove the word security from the specification (since this is to be handled in DAP).
>
> 4. Focus in the specification text only on declarative aspects of the intention of the author of the widget, leaving e.g. prompting aspects for DAP. I.e. assuming that the network access is conditional, what are the implications for the widget's code and author in case the network access is not present or its presence is dynamic? (e.g. provide a definition of the event mechanism).
>
> 5. In order to be able to define the IRI for network access feature, another document should probably be prepared that would also define the namespace for the further feature definitions (e.g. http://www.w3.org/widgetfeatures/).
>
> 6. Focus in the specification only on http and https. "subdomains" attribute / value of the parameter is valid mainly for this protocol family (also including e.g. rtsp, ftp etc.). Other schemes, like sms, tel, mms (there is no RFC for some) have their own specificities, e.g. country calling/dialing codes, shortcodes.
>
> Thanks.
>
> Kind regards,
> Marcin
>
> [1] http://www.w3.org/TR/2009/WD-widgets-access-20090804/

> [2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0290.html

> [3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0294.html

> [4] http://www.w3.org/TR/widgets

> [5] http://www.w3.org/TR/widgets/#the-feature-element

> [6] http://www.w3.org/TR/widgets/#the-widget-family-of-specifications

> [7] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#introduction

> [8] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#definitions

> [9] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#design-goals-and-requirements

> [10] http://www.w3.org/TR/widgets-reqs/#default-security-policy

> [11] http://www.w3.org/TR/widgets-reqs/#security-declarations

> [12] http://www.w3.org/2009/06/09-wam-minutes.html

> [13] http://www.w3.org/2009/05/DeviceAPICharter

> [14] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022264.html

>
> 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 Monday, 7 September 2009 11:28:34 UTC