[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] URLs for packages
I'm not sure I understand all this, but let me first try to outline my thoughts, then make some comments embedded. I think one can have relative URI references within a package that stay within the package. I see no reason to use fragment identifier syntax for them. I do not believe one can use URIs to go from outside a package to inside or from inside to outside. If it is a requirement to be able to reference a file outside the package from within, then that's what needs the special syntax. So I think we should use relative URIs to get around within a package, and then when the package is unzipped, those relative URIs will still work (which they wouldn't if we used fragment identifier syntax). I don't believe we have a need to go from outside a package to inside (I might be wrong here, but that's my current understanding). So the only thing we need to invent is how to go from inside to outside (e.g., to reference image1.png (a) from within content.xml (c)). More below. At 17:13 2003 12 19 +0100, Michael Brauer wrote: >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: In all these examples where you have "content.xml (a)", I assume you mean "context.xml (c)", or else I don't understand what you're trying to say here. >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 Actually, I wouldn't say that you can have a base URL (or any single URL for that matter) that starts outside a package and then goes down into a package. For the purposes of a single URL, the "top of" the package forms its own root like the root of a file system. >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 unzipped "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) I'm confused here by the reference to test.sxw which you did not show above in your set of files and packages. Also, from what you did show above, it doesn't look like image2.png (e) is in a test.sxw package, so of course that URL wouldn't reference it. But I agree with something I think you're saying: a relative URL within a package cannot go outside the package. >- 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. I agree that going from outside a package to down inside of it isn't doable with a single URL. >If we make these restriction, we might use a use definition like this for relative URLs within in package: > >If a URI is contained within a package sub file F, and if it is a 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 "/..", This is not really valid. (RFC 2396 shows such an example under C.2. Abnormal Examples and explains that this is really an error.) It does not result in a usable URI. > 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 I don't understand your "base URLs" here (or below), and even if I accept them, I don't see how the relative URI "image1.png" resolves to "image1.png (a)" as you mention below. >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 I'm still not understanding why we would want to use the fragment identifier syntax instead of relative URIs. I don't see how "image1.png" within content.xml (g) resolves to image1.png (a). paul >This solution has the following pros > >- URLs referencing files within the package and referencing files in the >file system can be differed. True, but we might instead make the "referencing files outside the package" the non-standard URI syntax to maintain the ability to tell the difference. >- 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 unzipped "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 > > >To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/office/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]