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

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.

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?

BR

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Friday, 28 November 2008 15:56:42 UTC