Re: ACTION-315: Widget URI scheme thoughts

Jon,

I was proposing to *not* have a widget URI scheme, and outlining how  
to make that work.  Note that, since we're talking about DOM-based  
technology, both the origin and the base URI are actually important  
properties to consider.

Regards,
--
Thomas Roessler, W3C  <tlr@w3.org>







On 26 Feb 2009, at 15:52, Jon Ferraiolo wrote:

> 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
>
>
> <graycol.gif>Thomas Roessler <tlr@w3.org>
>
>
> Thomas Roessler <tlr@w3.org>
> Sent by: public-webapps-request@w3.org
> 02/26/2009 04:54 AM
>
> <ecblank.gif>
> To
> <ecblank.gif>
> Thomas Roessler <tlr@w3.org>
> <ecblank.gif>
> cc
> <ecblank.gif>
> "public-webapps@w3.org WG" <public-webapps@w3.org>, public-pkg-uri-scheme@w3.org
> <ecblank.gif>
> Subject
> <ecblank.gif>
> Re: ACTION-315: Widget URI scheme thoughts
> <ecblank.gif>	<ecblank.gif>
>
> 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 <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>
>
>