URLs for packages

[Michael Brauer <michael.brauer@sun.com>]

Dear TC members,

in preparation of our discussions regarding URLs used in packages, I
would like to summarize the three proposals we have. This includes some
examples. The following files (within a file system) are involved:

a) /folder/image1.png
b) /folder/package.sxw

packages.sxw is an package containing the following sub files

c) content.xml
d) styles.xml
e) image2.png
f) Object1/
g) Object1/content.xml
h) Object1/styles.xml
i) Object1/image3.png

For simplicity, I've assigned letters to these files that I will use in
the examples

Propasal 1: relative URLs
-------------------------
In this proposal, we assume that the package is interpreted as a folder
within the file system. Relative URLs are used to reference sub files of
the package, but can also be used to reference files within the file 
system. The base URL in both cases is the URL of the package sub file 
that contains the URL.

Examples:

Package sub file
containing the URL    Base URL for files in file system
-----------------------------------------------------------
content.xml (a)       /folder/package1.sxw/content.xml
content.xml (g)       /folder/package1.sxw/Object1/content.xml

Package sub file
containing the URL    Base URL for package sub files
-----------------------------------------------------------
content.xml (a)       /folder/package1.sxw/content.xml
content.xml (g)       /folder/package1.sxw/Object1/content.xml


Pckage sub file       Referenced Sub      URL
containing the URL    File or File
-----------------------------------------------------------
content.xml (a)       image2.png (e)      image2.png
content.xml (a)       Object1 (f)         Object1
content.xml (a)       image1.png (a)      ../image1.png

content.xml (g)       image3.png (i)      image3.png
content.xml (g)       image1.png (a)      ../../image1.png

This solution has the following pros

- A package can be unziped "in place" and all URLs are still correct
- No new syntax for URL within packages has to be specified

It has the following cons

- Unless the whole package gets unzipped in the file system before it is
processed, the base URL is not a valid file system location.
- Unless the whole package gets unzipped in the file system before it is
processed, the base URL is not the one that has been used to retrieve
the file.
- relative URLs that reference files in the file system cannot be
resolved without knowledge of the package structure


If we agree to this proposal, it seems to be reasonable to me the make
the following restrictions to make sure that we do not change the
semantic of existing URL protocols:
- Within a package, only sub files within the same package can be referenced
- URLs that reference a sub file of a package must be relative, and they
must not contain paths that are not within the package. This means that
absolute URLs are not allowed, but also that the URL
../test.sxw/image2.png is not allowed to reference image2.png (e) from
content.xml (a)
- It cannot be assumed that a sub file of a package can be referenced
from outside the package. That is, we don't make any assumption whether
file:///folder/package.sxw/content.xml is a resolvable URL.

If we make these restriction, we might use a use definition like this 
for relative URLs within in package:

If an URI is contained within a package sub file F, and if it is an 
relative-path reference as described in chapter 5 of RFC2396 (this means 
the URI does neither contain a protocol nor does it start with /), then 
it has to be resolved as described in chapter 5.2 of RFC 2396, using any 
base URI whose schema specific part is an absolute path that equals the 
absolute path of F within the package.

If the resulting URI's path component starts with "/..", then the "/" 
needs to be removed, and the resulting URI is resolved using the base 
URI of the package itself. In any other case, the resulting URI has to 
be interpreted as the absolute path referencing a package sub file.



Propasals 2a: fragement identifiers with relative paths
-------------------------------------------------------
In this proposal, sub files within a package are referenced by fragment
identifiers like #package(image2.png). The base of relative paths within
the #package is the package sub file that contains the URL. The base URL 
for all files in the file system is the URL of the package.

Examples:

Package sub file
containing the URL    Base URL for files in file system
-----------------------------------------------------------
content.xml (a)       /folder/package1.sxw
content.xml (g)       /folder/package1.sxw


Package sub file
containing the URL    Base URL for package sub files
-----------------------------------------------------------
content.xml (a)       /content.xml
content.xml (g)       /Object1/content.xml


Pckage sub file       Referenced Sub      URL
containing the URL    File or File
-----------------------------------------------------------
content.xml (a)       image2.png (e)      #package(image2.png)
content.xml (a)       Object1 (f)         #package(Object1)
content.xml (a)       image1.png (a)      image1.png

content.xml (g)       image3.png (i)      #package(image3.png)
content.xml (g)       image1.png (a)      image1.png


This solution has the following pros

- URLs referencing files within the package and referencing files in the
file system can be differed.
- the base URL for references in the file system is the one that has 
been used to retrieve the package file.
- The non-fragment parts of all URLs are valid files system locations.
- relative URLs that reference files in the file system can be resolved
without knowledge of the package structure.


It has the following cons
- fragment identifiers are only valid if MIME types are specified, so we 
have to register MIME types.
- If a package is unziped "in place", the relative URLs that reference
files in the file system become invalid, and the ones that reference sub
files within the package need an extra processing as well.


Propasals 2b: fragement identifiers with absolute paths
-------------------------------------------------------
In this proposal equals propsal 2a, except that the base of relative
paths within the package is the package root.

Examples:

Package sub file
containing the URL    Base URL for files in file system
-----------------------------------------------------------
content.xml (a)       /folder/package1.sxw
content.xml (g)       /folder/package1.sxw


Package sub file
containing the URL    Base URL for package sub files
-----------------------------------------------------------
content.xml (a)       /
content.xml (g)       /


Pckage sub file       Referenced Sub      URL
containing the URL    File or File
-----------------------------------------------------------
content.xml (a)       image2.png (e)      #package(/image2.png)
content.xml (a)       Object1 (f)         #package(/Object1)
content.xml (a)       image1.png (a)      image1.png

content.xml (g)       image3.png (i)      #package(/Object1/image3.png)
content.xml (g)       image1.png (a)      image1.png


This solution has the same pros and cons as propsal 2a.

Best regards

Michael