This thread seems to have died out without further follow-up. What
are the next steps?
--
Thomas Roessler, W3C <[email protected]>
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 <[email protected]>
