[OASIS Issue Tracker] Commented: (OIC-5) Plugfest, subpackages(chart in spreadsheet)

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/OIC-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20061#action_20061 ] 

Dennis Hamilton commented on OIC-5:
-----------------------------------

Svante, this is an interesting comment, but I have no idea what you mean by normalization here.  This is not any normalization that is defined in the URI specification, is it?  There is no normalization currently defined in the ODF specification either, is that right?

Also, there is a complex set of interlocking technical considerations here, and I believe, as I said on today's call, that the ODF TC is the appropriate place to sort this out.

 - Dennis

A Few Observations:

The leading ./ is irrelevant in resolution of relative URI references in a package.  It is resolved exactly the same as if the ./ is not there, the same as relative no-scheme URI references everywhere.  The only reason for having it in a no-scheme relative URI reference is if the segment immediately after the ./ has a colon in it.  This is to prevent the URI reference being ambiguously-recognized as one having a scheme name.  

(Aside: Also, there should never be a "./" in a manifest:full-path because it is not a URI reference of any kind, it is a mapping to package files and subdocuments with their mime types, encryption information, etc., and we would not put "./" on the front of names in the Zip directory for any useful purpose.

(Aside: Since there may be many different relative URIs that reference relative to a full-path segment, it is probably preferable to simply not allow ":" anywhere in manifest:full-path and in the names of files in the Zip directory, so one can reliably create no-scheme relative URIs involving them with no problem.)

PS: I notice in recent versions of OO.o that there is a manifest entry created for every "directory" whether it is really a subdocument root or not, and a blank MIME type is used for most of them.  There is no reason for this in terms of the needs of ODF, and there is no provision in the ODF specification for empty strings as the value of the manifest:media-type attribute.
   In ODF 1.0/1.1 it was stated that a "directory" entry is needed only if there is a subdocument having that full-path as a prefix (i.e., root name) for all files (and interior subdocuments) that it contains.  It establishes the subdocument and also establishes the MIME type.

 (The manifest:full-path="/" is a special case, because the leading "/" does not appear on the names of files in the ZIp directory nor does it appear in the front of  manifest:full-path entries for those and any subdocuments.).  

> Plugfest, subpackages (chart in spreadsheet)
> --------------------------------------------
>
>                 Key: OIC-5
>                 URL: http://tools.oasis-open.org/issues/browse/OIC-5
>             Project: OASIS Open Document Format Interoperability and Conformance (OIC) TC
>          Issue Type: Improvement
>          Components: ODF11-InteropProfile
>            Reporter: Bart Hanssens
>            Assignee: Bart Hanssens
>             Fix For: Working Draft
>
>
> From the tests performed on the The Hague plugtest wiki.
> Testing spreadsheets with an embedded chart revealed that some implementations use 
> <draw:object xlink:href="./Object 1"...
> While other(s) use:
> <draw:object xlink:href="Object 1/"...
> (The latter seems to be better)
> ODF 1.1 mentions sub packages in 9.3.3 Objects (Object Data), but  the wording can be improved
> "For objects that have an XML representation, the link references the sub package of the object. The object is contained within this sub page exactly as it would as it is a document of its own."
> And perhaps 17.5, Usage of IRIs Within Packages
> "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."

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