Re: [office] 17.5 on IRIs

["Bob Jolliffe" <bobjolliffe@gmail.com>]

Dennis and others

2008/9/23 Dennis E. Hamilton <dennis.hamilton@acm.org>:
> Patrick and others,
>
> A quick question.  My reading of this ISO 26300 passage
>
> "A relative-path reference (as described in §6.5 of [RFC3987]) that occurs
> in a file that is contained in a package has to be resolved exactly as it
> would be resolved if the whole package gets unzipped into a directory at its
> current location. The base IRI for resolving relative-path references is the
> one that has to be used to retrieve the (unzipped) file that contains the
> relative-path reference."
>
> is that the base IRI is the Zip-file "path" to the sub-file that contains
> the relative-path reference.

I can't speak for all cases but there is at least one case where this
is not so.  Document signatures, as produced by OpenOffice, are
contained in a file within the package called
META-INF/documentsignatures.xml.  Signatures contain relative IRI
references (actually URI) to the streams which are signed.  So, for
example, we find <Reference URI="content.xml">.  Note this IRI is
relative to the root of the package, and not "the sub-file which
contains the relative-path reference".  Otherwise it should be
<Reference URI="../content.xml"> , which I think would actually be
better, but so be it.  These signatures are not documented in the
standard, so technically they could be changed, but that would break
all the existing signature implementations.

On the basis of my experience above, I have worked on the assumption
that the way to interpret a relative IRI is that it is always relative
to the root directory of the package.

> So the relative path may need to be
> de-"../"-ed and the correct prefix pushed onto what's left to make the Zip
> file name that is used.   Of course, if de-"../"-ing exceeds the path depth
> of the sub-file, we know that the remainder must be used with the host-OS
> file system.
>
> For the most part (e.g., in the content.xml file), the in-package relative
> URIs start with "./" followed by what is actually the Zip filename for the
> referenced object.

This starts to stretch the meaning of relative and is quite strange.
What happens if you rename the file?  Does this break all the internal
references?  Or what if the package doesn't have a filename?  It
doesn't need to have if it is in-memory or being streamed from a file
descriptor like a socket.

>
> I have a master document and the way it's content.xml file references the
> related component documents is via relative URIs such as
> "../MasterChecker2.odt".
>
> I have no handy ODF samples with any XML files below the top level of the
> package that also have relative URIs in them.  The manifest.xml file is not
> at the top level, but its file references are all via manifest:full-path
> references and these are strings, not URIs.  In fact, they are like Zip
> filenames for Zip package parts (and some empty directory-named parts)
> although there is no description in the ODF specification of the format or
> encoding of these attribute values.
>
> But we seem to have enough evidence that the base IRI for relative-path
> references is the IRI of the container of the package sub-file that contains
> the references

I've attached an example signature file as evidence of the opposite.

>
> So this particular paragraph seems perfectly clear.  In 17.5, it is only the
> final paragraph that is lacking, and the list at the beginning of the
> section is problematic too.

Unfortunately it looks like we have two distinct inconsistencies here.
 One related to what exactly a relative IRI is relative to - there are
two possibilities and we have evidence of both.

The other is whether  IRI="./somefile" refers to some sibling file in
the filesystem relative to the package or to some sub file in the root
in the package.  Again it seems we have evidence of both.

The simplistic formula of relative IRI's for references inside the
package and absolute IRI's for references outside the package (the
blissful ignorance i was living in) is not complete enough.

Now if it is only the IRI's in the digital signatures which behave
differently then we can describe them as a special case.  Or simply
ignore the occurrence altogether for now.  They are anyway not
described in detail (yet!) in the standard.  This resolves the first
ambiguity above and potentially the second.

I am not sure if, longer term, there is any alternative to assuming a
scheme other than "file://" for dealing with internal references in an
odf package.  There is as yet no existing, widely implemented
standard, as far as I know, for the equivalent for something like
"zipfs://.." or "package://" or "odf://".  Without it, we seem to be
in a sea of special cases and inconsistencies.  Given that these IRI's
are only for internal use within the package (which require special
processing with IRI dereferencing hooks anyway), there is nothing to
prevent the implementation of something like "odf://" but one is
tempted to think the problem is more general (war, jar, opc etc) and
deserving of a more collaborative solution.  Either way they are
longer term issues.

Bob

>
>  - Dennis
>
> -----Original Message-----
> From: Patrick Durusau [mailto:patrick@durusau.net]
> Sent: Monday, September 22, 2008 09:55
> To: ODF office
> Subject: [office] 17.5 on IRIs
>
> Greetings,
>
> To continue the discussion from the call this morning, I would call
> everyone's attention to a prior suggestion by Michael (I overlooked this):
>
>> *Every IRI reference that is not a relative-path reference does* not
>> > need any special processing. This especially means that absolute-paths
>> > do not reference files inside the package, but within the hierarchy the
>> > package is contained in, for instance the file system. IRI references
>> > inside a package may leave the package, but once they have left the
>> > package, they never can return into the package or another one.
> Note that we still have:
>
> "but within the hierarchy the package is contained in, for instance the
> file system."
>
> which doesn't make sense, or at least not at first.
>
> To some degree guessing on my part but I think the language of both the
> first and second sentence were meant to be talking about IRIs that are
> not relative paths.
>
> Thus:
>
> First sentence: wants to say: No special rules for non-relative path
> references. (ok by me)
>
> Second sentence wants to say: Repeats about absolute paths don't
> reference files in the package (repetition but ok) *and* that absolute
> path IRI can reference packages, for example in a file system.
>
> In other words, the second part of the second sentence was simply an
> *observation* about the capacity of an absolute path IRI.
>
> Third sentence wants to say: IRI can point to something outside the
> package (ok) but once it leaves it can't come back. ???
>
> Well, but IRIs only point to one location and since we don't have link
> hubs (XLink feature) there is no known mechanism for a single IRI to
> point outside of a package and then back into a package. Noting that we
> have already said that absolute IRI can't point into a package.
>
> OK, having gone the long way around (apologies but I wanted it to be
> clear that remarks from others and not any cleverness on my part has
> resulted in the following) here is what I would propose to "fix" the
> paragraph in question:
>
> ****
> Every IRI reference that is not a relative-path reference does not need
> any special processing. Absolute-paths can not reference files inside a
> package, but may, for instance, address packages that are held in a file
> hierarchy. IRI references inside a package may address anything
> addressable by an IRI that is outside of a package, but no IRI outside
> of a package may address any location within any package.
> ****
>
> A bit wordy for me and I would suggest further edits on the second
> sentence, now that I suspect we know what was meant and to replace the
> paragraph with:
>
> ****
> Every IRI reference that is not a relative-path reference does not need
> any special processing. Absolute-paths can not reference files inside a
> package. IRI references inside a package may address anything
> addressable by an IRI that is outside of a package, but no IRI outside
> of a package may address any location within any package
> ****
>
> The second half of the third sentence strikes me as redundant with the
> second sentence. So, my personal preference would be:
>
> ****
> Every IRI reference that is not a relative-path reference does not need
> any special processing. An absolute-path IRI can not reference files
> inside a package. IRI references inside a package may address anything
> addressable by an IRI that is outside of a package.
> ****
>
> Note that I started to say "that is outside of *the* package" to make
> reference to the package containing the IRI but that would be wrong
> because we don't want absolute IRIs addressing files in *any* package.
>
> Hope everyone is having a great day!
>
> Patrick
>
> --
> Patrick Durusau
> patrick@durusau.net
> Chair, V1 - US TAG to JTC 1/SC 34
> Convener, JTC 1/SC 34/WG 3 (Topic Maps)
> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>