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

Hello Marcos,

> -----Original Message-----
> From: Marcos Caceres [mailto:marcosscaceres@gmail.com]
> Sent: 28 November 2008 20:12
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: www-tag@w3.org; public-webapps
> Subject: 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].

[Aside: Hmmm process wise that would create a dependency on the publication of HTML 5 are you sure that you want to do that?]

Well there are ways around that, add a package description or meta-data file either at the root of the package or at each directory level and have it carry media-type information - or use 'magic numbers' or (if you really must - in the absense of other authoritative information), sniff/guess though I think that should be the least preferred option.

Anyway - that zip files don't intrinically maintain such info is not a show stopper - though I would have thought that carrying media-type information is a natural requirement for a packaging format for the web.


> > 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.

Ok... but you answered a different question.

I asked which of your requirements would an approach like this *fail* to meet?

I could paraphrase your response as:

        "That would work, but it does more than we need."

Dan Brickley's response[a] emphasised the need for nesting packages in packages. Even if that is not a capability that widgets would need to use, widgets could still share the same syntax.

Anyway... I think that my sketch shows that there is a potential to develop a media-type + fragID-syntax based solution to the package component/widget addressing problem.

>
> 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

Regards

Stuart
--
[a] http://lists.w3.org/Archives/Public/www-tag/2008Nov/0120.html

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

Received on Monday, 1 December 2008 10:33:05 UTC