Re: ACTION-315: Widget URI scheme thoughts

This thread seems to have died out without further follow-up.  What  
are the next steps?
--
Thomas Roessler, W3C  <tlr@w3.org>







On 26 Feb 2009, at 13:23, Thomas Roessler wrote:

> Getting back to the URI scheme discussion, here's a strawman  
> proposal that's inspired by the Widget case, where scripting and  
> navigation add a few more complexities.  I'll be interested in  
> seeing Marcos, Arve and Josh shoot this one down. :)
>
> Specifically, we need to say:
>
> - how to dereference a URI reference that occurs within a widget  
> resource, and for which the identified resource is included within  
> the widget package
>
> - what the base URI property is for any DOM created from a resource  
> within a widget package
>
> - what the origin is for any DOM created by the Widget. (e.g., for  
> cross-frame scripting)
>
> The critically important point here is that we separate the Origin  
> consideration from the identification and retrieval of resources in  
> the package.
>
> Design assumptions:
>
> - we can synthesize origins to be globally unique identifiers (as  
> HTML5 does)
> - we have unique identifiers resources within the package.  
> Typically, these will look filesystem path like, but for the  
> purposes of this proposal, they're opaque identifiers, and totally  
> depend on the package format.
>
> Proposal:
>
> 1. The manifest is turned into a generic indirection tool that can  
> aim inside the widget.  For each resource (identified by absolute  
> URI), the following properties are defined:
>
>  - Content-Type
>  - Parameters for said Content-Type
>  - identifier for the packaged file that includes a representation  
> of this resource
>
> E.g.:
>
>   <Resource Identifier="http://www.w3.org/">
>     <ContentInfo Type="text/html">
>       <Parameter Name="charset">iso-8859-1</Parameter>
>       <Parameter Name="foo">bar</Parameter>
>     </ContentInfo>
>     <Representation>/www.w3.org/Overview.html</Representation>
>   </Resource>
>
> Or:
>
>   <Resource Identifier="http://www.w3.org/">
>     <ContentInfo Type="text/html">
>       <Parameter Name="charset">utf-8</Parameter>
>       <Parameter Name="foo">bar</Parameter>
>     </ContentInfo>
>     <Representation>L3d3dy53My5vcmcvT3ZlcnZpZXcuaHRtbAo</ 
> Representation>
>   </Resource>
>
> Or:
>
>   <Resource Identifier="http://www.w3.org/">
>     <ContentInfo Type="text/html">
>        <Parameter Name="charset">windows-1251</Parameter>
>     </ContentInfo>
>     <Representation>\SITES\CONSORTIUM\ROOT</Representation>
>   </Resource>
>
> ;-)
>
> (As an aside, note that it might be important to have an extension  
> point for content type specific parameters here.)
>
> 2. When a widget is instantiated, a new globally unique identifier  
> is coined for that instance, at run time. Whenever a resource is  
> retrieved through the manifest indirection, this globally unique  
> identifier is used to construct the relevant origin, not the URI  
> that was used to identify the resource.  (This effectively turns  
> each widget instance into a trust domain of its own within HTML's  
> security model, but only includes those resources in that domain  
> that are packaged up.)
>
> 3. When a widget navigates to a resource, then the base URI is the  
> URI that was used to *identify* this resource.
>
>
> In the example above, that would mean that no matter what the  
> packaging format does, the base URI will be "http://www.w3.org/",  
> and relative URI references will be resolved relative to it.
>
> Note that this proposal would require:
>
> 1. Making the manifest mandatory.
> 2. Mild changes to the packaging spec (in particular, the start file  
> needs to be identified by absolute URI, e.g., htp://..., and through  
> the manifest mechanism, to give an initial base URI)
>
>
> It will be an important security consideration to note that the  
> manifest-driven resource retrieval MUST NOT leak outside the context  
> of the widget engine.
>
> Thoughts? Feedback?
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>