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


Hi Bob,

On 09/23/08 11:28, Bob Jolliffe wrote:
> 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.

That's a good point. I believe the reason OOo writes "content.xml" 
rather than "../content.xml" is that we consider all streams within 
META-INF to be information that belongs to the package itself rather 
than to the content that is stored within the package, and that we 
therefore have used the same convention as for the manifest.xml. In the 
manifest.xml, we are not using URIs but paths, and the paths are 
relative to the package root.

But of the cause, the URI attributes takes an URI rather than a path. 
Therefore, unless we state otherwise, it can be assumed that the rules 
regarding IRI processing apply here. We therefore should either state in 
the description of the digital signature feature that these URIs relate 
to the package root, or we should adapt OOo. But even in the later case, 
a clarifying sentence within the description of the signature feature 
may be helpful.

Anyway, that is something we have to address for ODF 1.2. Since digital 
signatures are not part of ODF 1.0, this issue does not matter there.

> 
> 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.

That is the reason we only allow relative-paths for referencing files 
within the package. And while I am not 100% sure, I believe this is 
exactly why we added the note that

"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."

> 
>> 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.

We do not have an inconsistency in ODF 1.0 and 1.1. We may have one in 
ODF 1.2 only regarding the use of the URI attribute in digital 
signatures. We should resolve that, but I don't think we need to 
consider this case for the ODF 1.0 errata.

> 
> 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 ODF 1.0/1.1 and even the ODF 1.2 spec are clear in this regard. They 
state:

"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."

It is only the digital signature implementation in OpenOffice.org that 
behaves differently. The simple question is whether this is reasonable 
and that we therefore should state that exception in the ODF 1.2 
specification, or whether we simply should consider this behavior as a 
bug in OpenOffice.org.

Best regards

Michael

-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]