My opinion is that having a widget URI scheme is not worth all of this complexity. I propose that the W3C ship Widgets 1.0 as quickly as possible with less flexibility on URI addressing. I think it is acceptable for a 1.0 release if all assets in the ZIP can only be addressed by relative addressing without allowing "/" at the front of the relative URL. In my experience a few years ago at Adobe which used ZIP packaging for its Digital Editions products (based on IDPF standards) and its Mars technology (PDF in XML/ZIP), people were able to deal with the restriction that relative addressed could not start with "/". I definitely know that OpenAjax Widgets get by without a widget URI scheme, and I'll 99% sure that Google/OpenSocial Gadgets doesn't have such a mechanism.
Jon
Thomas Roessler
<t...@w3.org>
Sent by: To
public-webapps-re Thomas Roessler <t...@w3.org>
qu...@w3.org cc
"public-webapps@w3.org WG"
<public-webapps@w3.org>,
02/26/2009 04:54 public-pkg-uri-sch...@w3.org
AM Subject
Re: ACTION-315: Widget URI scheme
thoughts
As a follow-up from trashing this through with Josh, the one open issue is
navigation of iframes: Assume a widget frames a resource that is retrieved
from the Web. Would navigation of that iframe have to go through the
manifest based indirection or not?
The sense in our conversation was that it should *not* go through that
indirection, but that that would probably have the potential to cause some
surprises.
The basic behavior would be that the manifest is only used for resolution
of URI references that have the widget instance's unique origin; anything
else would bypass the manifest mechanism.
The other point would be HTTP POST (from forms): The manifest mechanism is
right now scoped to the *retrieval* of resources.
Form posts, XMLHttpRequest and other mechanisms are out of scope,
therefore, standard HTML behavior (e.g., going out on the network) would
apply. The synthetic origin approach seems to lead to the intended results
in terms of security policy as far as the discussion between Josh and
myself was concerned; I understand that Josh has some ideas about writing
POST-like handlers in JavaScript, but that would be another extension.
--
Thomas Roessler, W3C <t...@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 <t...@w3.org:>
<<inline: graycol.gif>>
<<inline: pic19838.gif>>
<<inline: ecblank.gif>>
