Re: ACTION-315: Widget URI scheme thoughts

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                                               
             <tlr@w3.org>                                                  
             Sent by:                                                   To 
             public-webapps-re         Thomas Roessler <tlr@w3.org>        
             quest@w3.org                                               cc 
                                       "public-webapps@w3.org WG"          
                                       <public-webapps@w3.org>,            
             02/26/2009 04:54          public-pkg-uri-scheme@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  <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:>