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


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]