FYI
When faced with this question in MPEG (MPEG-21 files are container
files too), we consulted with folks at the W3C (in Cannes, if I
recall correctly) and decided:
a) that a scheme type was wrong, and that 'picking a piece out of an
archive' at the client-side was almost the definition of what a
fragment was for;
b) to solve the 'stacked fragments' by using a * for the second one
(a character not allowed in fragments, if I recall correctly)
c) that the contents of the container, once fetched and un-packed,
logically 'shadow' the directory where the container came from.
So, imagine a container x.m21 containing y.html and z.jpg. We want
to see anchor-point q in y.html, with the jpeg in the page.
the 'external' pointer reads
http://www.example.com/x.m21#y.html*q
this causes the m21 file to be fetched and unpacked, and then
interpreted as if its source URI was
http://www.example.com/y.html#q
y.html has been pre-cached as a result of the unpack operation, and
the re-write of the URI has eliminated x.21 and re-written the first
* after the # (which has gone) as a #. So we find y.html and go to
anchor q.
In y.html,
<img src="z.jpg" ...
now refers to the pre-cached z.jpg also.
I believe under these circumstances document analysis for schemes
used works, relative URLs work, and documents do not need re-writing
when they are packed, if they use relative URLs.
--
David Singer
Apple/QuickTime
