Re: [WARP] Comments to WARP spec

Marcin Hanclik wrote:
> 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?
>

My view is that all this is overkill. I would prefer to keep things simple.

To add the above would mean that a UA would have to flag every single 
element and every future supported element, as well as every feature, 
into a particular class (or into multiple classes or worst, do this 
dynamically (e.g., <script style="display: block; 
background-color:red;">...</script>)). This proposal does not scale either.

Kind regards,
Marcos

Received on Thursday, 12 November 2009 14:04:50 UTC