RE: [WARP] Comments to WARP spec

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: marcin.hanclik@access-company.com

-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] 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.

Received on Thursday, 12 November 2009 13:57:03 UTC