[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] 17.5 on IRIs
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. 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. 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. 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. - 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]