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@[17.202.35.52]>
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
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