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

ext Williams, Stuart (HP Labs, Bristol) wrote:

...

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

Is it not the case that a zip file containing widgets is a 
representation of an HTTP resource in its own right? If so, couldn't the 
HTTP header returned in response to a request for that resource contain 
an HTTP Link header [1] providing a link to another HTTP resource which 
provides the package metadata, including links to the individual 
resources contained within the zip file?

Could the package metadata be represented in a common format like Atom, 
since it is a collection of links to other resources?

Regards,

- johnk

[1] 
http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-03.txt

Received on Monday, 1 December 2008 15:36:46 UTC