W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2008

[whatwg] Application deployment

From: Dave Singer <singer@apple.com>
Date: Mon, 28 Jul 2008 13:02:49 -0700
Message-ID: <p0624080fc4b3d47a9de7@[]>

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


this causes the m21 file to be fetched and unpacked, and then 
interpreted as if its source URI was

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
Received on Monday, 28 July 2008 13:02:49 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:03 UTC