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: [OASIS Issue Tracker] Commented: (OFFICE-2685) NEEDS-DISCUSSION:ODF 1.2 Part 3 "IRI" and "relative IRI" used throughout are never defined

    [ http://tools.oasis-open.org/issues/browse/OFFICE-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20636#action_20636 ] 

Michael Brauer commented on OFFICE-2685:

Dennis: A few comments

1. I agree that we should add a reference to RFC3987 in section 3.7, and maybe also 4.3. This defines properly what we mean by "IRI" in these two sections.
2. That reference also makes clear what we mean by a relative IRI, since RFC 3987 also uses that term.
3. I further agree that the manifest:full-path values shall match the names of the entries in the Zip file's central directory. That's said already in the specification, as well as that the character encodings of two may differ.
4. Regarding the encoding of file names in the Zip file as IRIs: I think in practice it is clear to everyone who implements ODF that the resolution of relative IRIs includes conversions of character encodings, and possible encoding of path fragments as IRIs. In need to think about this, but we may anyway have to be more precise here. However, I'm wondering whether we maybe can simplify the full resolution of relative IRIs here. The question whether a relative IRI is a reference to an external file or one into a zip file solely depends on the number of "../"s. And a reference to file in the Zip file further can be turned into file name (within the Zip file) without eve constructing an IRI.

Having that said: Before we start to extend the current description to cover encodings and the like, I would like to provide a refined resolution algorithm that makes less use of IRI details for the resolution of package file entry references.

> NEEDS-DISCUSSION: ODF 1.2 Part 3 "IRI" and "relative IRI" used throughout are never defined
> -------------------------------------------------------------------------------------------
>                 Key: OFFICE-2685
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2685
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Packaging, Part 3 (Packages), Schema and Datatypes
>    Affects Versions: ODF 1.2 CD 05
>         Environment: This applies to all versions of OpenDocument-v1.2-part3-cd1 through -rev04.  It also impacts ODF 1.2 Part 1 and ODF 1.2 Part 2 wherever anyURI or equivalent datatype is used in a relative reference.
>            Reporter: Dennis Hamilton
>            Assignee: Dennis Hamilton
>             Fix For: ODF 1.2 CD 06
> The terms "IRI" and "relative IRI" are used throughout ODF 1.2 Part 3.  
> 1. There are no definitions offered for these terms.
>  2. There are no references (normative or otherwise) to sources on this terminology (although [RFC3987] would appear to be a good choice).
>  3. The manner in which IRIs are to be mapped to URIs in those places where resolution involves URI segments within a package is not defined, nor is the relationship to IRI-encoding in URIs accounted for in the definition of (a) the manifest:full-path attribute or (b) the format for names of files in the ZIP data units that carry files within the ZIP archive.  In particular, there should be attention to [RFC3987] sections 6.2-6.4, not merely 6.5.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


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