Hi, What about semantic distinctions? "tag" as proposed till now seems to be too detailed and does not scale. For HTML/XHR: <script> means an executable content retrieved from the remote host. <img>, <video> etc means a displayable content retrieved from the remote host. <iframe> means a container (possibly for executable and displayable content) retrieved from the remote host. <form> means form submission, i.e. data is sent and not retrieved (topic discussed at TPAC. This also relates to the notion of retrievable content that is currently defined in WARP). API means that the network resource is to be requested by some API and not markup.
We could have similar model to @rel on <link> from HTML, i.e. some meta information. We probably would like to distinguish between executable/non-executable (e.g. displayable or styling) contents and a kind of containers into which we have/not have insights. Keeping WARP on an abstract level, we could specify that the semantics of the particular content in the WARP model is out of scope for WARP. Then e.g. for HTML we could adopt the above distinctions in some other spec. It should work for HTML+SVG. The proposal is: add "type" attribute on "access" element that must have a value that is a set of space-separated tokens: "exec" - any retrievable content that is executed within the user agent (i.e. something that - when retrieved - will be executed), "display" - any retrievable content that is (only) displayed by the user agent, "form" - any data submitted by the user agent, "container" - any (markup) container that could be used to load executable, displayable or any other type of content by the user agent (i.e. e.g. some html page. This touches upon <a> being clicked in a widget: should the browser be opened? ), "api" - any retrievable and displayable content that is to be processed by the executable content within the user agent (e.g. by XHR. But what to do with the submissions based on XHR...? It seems API blurs this model a bit, since it is undefined what would happened to the retrieved data. Also e.g. the retrieved XML may be "executed" by some processor developed in script.), "any" - all/any of the above. Missing value equals to "any" (the default). This attribute specifies the origin of the access request and purpose for the submitted/retrieved data. Any views on this? 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: [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Marcos Caceres Sent: Tuesday, November 10, 2009 4:30 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: WebApps WG Subject: Re: [WARP] Comments to WARP spec SULLIVAN, BRYAN L (ATTCINW) wrote: > Marcos, > I agree there is an assumption behind the approach I proposed, which I also > believe will be valid for the vast majority of widgets which will actually > have "index.html" or something like that as the start page. Further, the > statements in the config.xml apply to all resources in the widget, not just > the start page, i.e. I can start with a non-HTML which references an HTML > file in the package, to which the "tag" attribute applies. So we are clear, the tag attribute does not work in the following situation. I want to disable x:script, but allow v:script... unless you know what the things different namespaces will not be added dynamically to the DOM: <x:html xmlns:x="http://www.w3.org/1999/xhtml";> ... <x:script> ... </x:script> <v:svg v:width="6cm" v:height="5cm" v:viewBox="0 0 600 500" xmlns:v="http://www.w3.org/2000/svg"; version="1.1"> <v:script src="...">...</v:script> </v:svg> </x:html> > If the proposed solution is inadequate, I welcome other suggestions. I don't have a suggestion because I don't believe this part of WARP is broken or is necessary. >But as it stands, the WARP spec is not consistent with the web security model, so we need to fix the<access> element definition somehow. Well, the whole point of WARP is to put these boundaries around the behavior of widgets because they run locally. How a browsing context should behave when run locally is not really defined by HTML5. This leaves a gap for us to fill. ________________________________________ 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.
