[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] 17.5 on IRIs
I forgot to attach documentsignatures.xml to previous post. Here's the relevant section anyway: <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="content.xml"> <Transforms> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>2vBnfURPkfDXxUACDTOIwqlNcjg=</DigestValue> </Reference> <Reference URI="styles.xml"> <Transforms> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>B2GzuX3I+kHqRYbvpZ3oHvHLW/s=</DigestValue> </Reference> ... etc etc 2008/9/23 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 >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]