Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

On Fri, Nov 28, 2008 at 3:52 PM, Williams, Stuart (HP Labs, Bristol)
<skw@hp.com> wrote:
> I just wanted to float an outline of a not very baked idea for trying to solve the "widget referencing" problem with a media-type/fragment identifer approach - those IMO being the 'right' extension point in the web architecture to be trying to use for this purpose - ie a frag id syntax to go with a new or refined media-type specification for a packaging format. One vital requirement for the packaging format is that it maintains media-types for the things that the package contains so that the whole approach can nest.
>
> This idea is inspired by (my half rememberings) of source routed email addresses where % get re-written to @ and right hand domains get eaten off of mail addresses so that say:
>
> skw!hp.com!isp.com!somerelay.com@example.com progresively becomes:
>
>        skw!hp.com!isp.com@somerelay.com ->
>        skw!hp.com@isp.com ->
>        skw@hp.com
>
> as the message is routed via example.com, somerelay.com, isp.com and finally hp.com.
>
> The approach below 'works' left to right stripping away the none fragment part of a URI and rewriting the leftmost ! in the remaining fragment with a # as one penetrates more deeply into a package structure.
>
> I don't mean to suggest that this is all properly worked out - I may have violated numerous character restrictions in URI syntax. But in principle I think something like this could meet the widget addressing (and more general thing within package addressing) problem entirely within fragID/media-type space (which then leave it properly orthogonal to URI scheme).
>
> Consider a package/containment structure as follow (where indentation represents path depth and  "n: [..]" represents named containment).
>
> outer:  [ catalog.xml
>          scripts
>            myScript.js
>          lib
>            myLib.lib
>            aLib.lib
>          nestedPackages
>            innerpkg: [
>              catalog.xml
>              scripts
>                 nestedScript.js
>              deeperPkgs
>                moreNestedPkg: [
>                   catalog.xml
>                   scripts
>                      deeplyNested.js
>                   ...
>                ]
>            ]
>            mypkg: [
>              catalog.xml
>            ]
>         ]
>
> An external reference to some target XML in the most deeply nested catalog.xml 'file' would look like this:
>
> scheme://<authority>/<path>/outer#/nestedPackages/innerpkg!/deeperPkgs/moreNestedPkg!/catalog.xml!targetXMLId
>
> Once focus shifts inside the outer package, references are re-written by replacing the leftmost ! with a # as follows:
>
> - from within "outer" -> /nestedPackages/innerpkg#/deeperPkgs/moreNestedPkg!/catalog.xml!targetXMLId
> - from within "innerpkg" -> /deeperPkgs/moreNestedPkg#/catalog.xml!targetXMLId
> - from within "moreNestedPkg" -> /catalog.xml#targetXMLId
>
> Relative references within a package hierarchy work as expected.
>
> Relative Referencing more deeply into the package structure is straight forward.
>
> Relative referencing up the hierarchy is not covered by this approach, though maybe another character could be reserved to act a bit like .. but at the package hierarchy level as opposed to internal to the package - I suppose that .. itself could be allowed to take you higher than the local package root - but some detailed work would have to be put in to checking compatibility with the normalisation of relative references in 3986.
>
> The assumption here is that the package format also maintains media-type information for each of the things that it contains that all the packages, "outer", "innerpkg", "moreNestedPkg" and "mypkg" are marked with a media-type that defines a fragment identifier syntax and re-write rules as illustrated above.
>

Unfortunately, widgets/zip do not maintain media-type information.
That information is derived from content-type sniffing heuristics as
defined in HTML5 [1].

> Other characters than / and ! could be choosen as path and container separators respective.
>
> Could this or something like it meet your requirements? If not... which ones does it fail to meet?
>

Nice solution. But, unfortunately, widgets don't support inner
packages (they inner packages are treated as arbitrary files) and we
have no requirements that call for inner package access.

Kind regards,
Marcos

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#content-type-0

-- 
Marcos Caceres
http://datadriven.com.au

Received on Friday, 28 November 2008 20:12:35 UTC