relative URLs [was: Action Items for todays meeting]

[Paul Grosso <pgrosso@arbortext.com>]

I'm not sure I understand all this, but I'm concerned that we
might be reinventing the wheel using non-standard parts.

RFC 2396 [1] and recent internet, XML, and web architecture in
general (e.g., XML Base [2]) defines what relative URI references
mean and how to write them.  I'm not sure we need to hide the
relative reference hierarchy in the fragment identifier (and
fragment identifiers belong to MIME types, so we can only define
a new fragment identifier if we are registering a new MIME type).

Insofar as we're talking about relative URI references, I think we
should be following the standards.

I'm not up to speed on just what a package is in OpenOffice, but
insofar as there are precedents, we should use them.

Perhaps we can discuss this on the call today.

paul

At 15:32 2003 12 15 +0100, Michael Brauer wrote:
>URLs within packages
>--------------------
>The OpenOffice.org file format specification does not specify what URLs that reference files within a package should look like. However, in the OpenOffice.org file format, references to files within a package are currently encoded into the fragment identifier. This means that in a package that contains the sub files
>
>content.xml
>meta.xml
>Pitures/Image1.png
>
>the following URL is used to reference Pictures/Image1.gif from inside content.xml:
>
>#Pictures/Image1.png.
>
>However, since this might collide with other schemas used inside fragment identifiers, I would like to propose to use a URL like
>
>#package( Pictures/Image1.png )
>
>instead. This in fact would be very similar to the XPointer specification (http://www.w3.org/TR/xptr-framework/) where the schema is
>
>#xpointer( ... )
>
>What needs to be specified separately is whether the paths within the fragment are interpreted as absolute paths with the package root as base or as relative paths with the file they are contained in as base. For simplicity, I would suggest to interpret them as absolute paths, but to specify that they have to start with a "/" so that we can support relative paths later on if we want to. The above example then would have to be
>
>#package( /Pictures/Image1.png )
>
>In any case, putting paths within packages into fragment identifiers means that URLs that reference files outside the package do not need any processing an behave as expected. Moreover, the base URL (for non package URLS) in all cases would be the package rather than the a file within the package. This means that a file "Image2.png" that is located next to the package in the file system still could be referenced by the URL
>
>Image1.png
>
>This has the large advantage that in a transformation of a content.xml included in a package into for instance HTML, only #package-URLs need any special handling. All other URLs do not need any special processing, and a differentiation between flat and pacakges office documents is not required. Moreover, to resolve a non package URL, it can be passed to the operating system unmodified and no knowledge about URL syntax is required at all.
>
>A third option where all this is not the case would be to use relative URLs within a package where it is assumed that the package behaves like a folder in the file system. The above example then would look like
>
>Pictures/Image1.png
>
>but the reference to the a file "Image2.png" located next to the package would be
>
>../Image2.png
>
>While this solutions looks very elegant at the first glance, it has the severe disadvantages that every URL needs to be checked whether it is a reference into the package or not (what is not even trivial) and that references to one and the same file would look different in flat and packaged office documents. For these reasons, I personally would not recommend to use these kind of URLs.