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<[email protected]> 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: [email protected] > > ________________________________________ > > 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
