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

Received on Friday, 4 September 2009 15:04:34 UTC