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
