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


Michael's rationale in response to Bob Jolliffe is consistent with the
evidence I found in some ODF documents produced with OO.o.  Relative-path
URIs are to be interpreted as relative to the location of the sub-file
containing the URI-valued attribute.

The following observations may be helpful in the comprehension of this
approach:

0. GLOBAL EDGE CASES (SELF-REFERENCE, etc.).  The problem of needing to know
the name of files at the end of relative paths is not new.  It is clearly a
brittle arrangement to embed the filename of the current package (or any
other) in a reference.  Likewise, referring to the same file-part having the
reference is easy to do and as interesting to make work (or not).  The
prospect exists in any path-based system that can navigate into, up,  and
down a hierarchy.  The prospect is equally-available for absolute paths.
There is no assurance that such a reference will work (not only because a
file is not present [with the expected name] but also because of locking and
so on.  On the other hand, I have on my computer a number of applications
that are smart enough to detect when a file already being worked on is
referenced and then make it work.  (I haven't tested any of them to see if
they can detect and prevent unending recursions, but that is rarely a
problem.  Notice that browsers don't mind.)

1. NOT USING URIs FOR COMPLETE PACKAGE PART REFERENCES.  Although the
manifest:full-path attribute is underspecified (i.e., not much description
at all) in ODF 1.0, it has a string value, not a URI value.  For sub-files,
it is the full in-Zip filename (that is, having the in-zip "path" built-in).
This attribute or maybe a package:full-path attribute might be co-opted for
the DSIG case (just making things up here).

2. PART-RELATIVE EASES NESTING.  The advantage of using the location of the
reference-bearing sub-file as the "base URI" is that embedding of one ODF
document in another via nesting in a single package (not a package in a
package) still works, and the embedded ODF document does not have to be
reprocessed in any way, simply imported into the appropriate nesting level
with prefixing of filenames to reflect the new nested location.

3. LACK OF WAY TO BE PACKAGE-RELATIVE.  The disadvantage of (2) is the
absence of a way to treat the top of the actual package as a "home" point.
It would be possible to co-opt "/" or even "~/" for this, but the first
contradicts other quite-clear provisions of 17.5 and the second is likely
misleading.  But other devices are possible.

4. BRITTLENESS OF GLOBAL DEPENDENCIES.  A problem with this hypothetical
nesting in (2) is that any package-relative paths that go global to the
nested package are now likely broken.  A device such as (3) would help, but
there is the problem of making sure that the external content is preserved
in its path-global location and that there are not name conflicts for
external content wanted by the containing document and nested documents.
(Although it doesn't solve name-conflict cases, if a package (e.g., an .odt
file) were nested in another package, the rule for relative global
references could always involve going to the location of the top-level
package.)

5. IMPROVING GLOBAL-DEPENDENCY MANAGEMENT.  The scenarios in (2-4) are
rather far-fetched and relative paths always turn out to be insufficient
for global references, one way or another.  The last time I worried about
such things (circa 1990-1992), we found that the ideal way to deal with
references global to packages was to use indirection.  That is, content
referred to an index in which external references were carried (the manifest
is a good place for this), and one could determine external/global
dependencies by inspection of the index without having to process the
content.  Under these conditions, relocation and renaming of material and
even dynamic adjustment when processing from a different place than the
index assumes can be handled in a reasonable way. But that is a whole
different game (although important when working with document-management and
content-management systems that should not touch or alter content in any
way).  This idea goes back even farther to systems for global-reference
management for pure procedures in Multics and the like.  And don't you just
love it when old fogeys talk about how they did it in a past century on
systems that no one remembers or cares about?     

 - Dennis

-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
Sent: Tuesday, September 23, 2008 07:50
To: Bob Jolliffe
Cc: office TC
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

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