ACTION-315: Widget URI scheme thoughts

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>