OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[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]