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