[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=13531#action_13531 ] 

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

Side note: I am not clear how this issue advances to some kind of recommendation, so I am speculating about that in this comment.

The deliverable is apparently an ODF Interoperability Profile which is a specification from this TC.  Resolution of this issue would appear to be (1) agreement on the problem (2) exploration of a suitable agreement for reconciling implementations, and (3) reflection of the agreement in the profile.

TECHNICAL CONSIDERATIONS:

There is an interaction between 17.5 and the way that a subdocument is reflected in the manifest for the main document (in 17.7).   We need to consider how the manifest is aligned in any proposed agreement..   A subdocument is presumably represented with a manifest:full-path value and a manifest:media-type value in a <manifest:file-entry> element.  For individual content items, the manifest:full-path value and the name of the Zip content item are presumably identical.   Any content items that are the components of the subdocument presumably have the subdocument manifest:full-path value as prefixes on their manifest:full-path values and Zip content-item names.  Some, not necessarily all, of these will have their own corresponding <manifest:file-entry> elements.  

Since there are no folders in Zip and no content items for folders, as such, the <manifest:file-entry> for  a subdocument has no corresponding Zip content item. The one example in the ODF specification (and only as an example) has manifest:full-path="/" with manifest:media-type being the MIME type of the package itself.  

So for starters, there is the question of what is the relationship between full-path values and content-item names, and what is that relationship when the full-path is for a conceptual folder that has no corresponding content-item, but there may be many content-items (or none) that have structurally-related names (and/or full-path attribute names).

Along with that, there is also the reconciliation of how IRIs that access other components of the same Package are to work.  This is where 17.5 comes in.

RECONCILING THIS

I suspect that there is a consistent way to deal with this and whatever it is, it has to work for whatever OO.o did in 2.x and does in 3.x.   

So we need to make some documents, using OO.o, that demonstrate how subdocuments and other use of folders having manifest entries are identified via manifest:full-path values and then how IRIs are created that refer to those.  

What is discovered in that experiment should then allow us to figure out a scenario for exploring how other implementations do this (using equivalent test-document creation procedures).  

We can then also see how other documents accept ones produced by the other implementations.

Then it requires some sort of alignment among the affected parties on how they can adjust implementations and how they can move forward in dealing with deviating legacy documents of whatever their origins are.

I suspect that a profile on this matter depends on what that alignment is.

This seems like something worthwhile for taking to the Orvieto-timeframe event, wherever it is.  We might also know, by then, what is proposed to be done about this matter, if anything, in ODF 1.2.

Finally, is there already something like a gentlemen's agreement out of the recent plugfest on what the answer is to the question of what the IRI is expected to look like (i.e., where does the "/" go when refering to a subpackage?  To a subpackage of a subpackage?

[PS: There are a number of open issues about subpackages.  For example: (1) it needs to be clear that the subpackage cannot have any mimetype, META-INF/manifest.xml, nor  Thumbnails/thumbnail.png content items; (2) It is meaningless for there to be encryption information in the <manifest:file-item> for a subdocument; (3) there are content-items having "/" within their names that have no corresponding <manifest:file-entry> element, and that are nonetheless accessible via IRIs from XML documents within the package (e.g., "images/mumble.jpg"); and (4) there is no specified agreement on the admissible character set, case sensitivity, and structural requirements for content-item names and the corresponding manifest:full-path values, if any.  One could easily see this problem of the path references to subdocuments as just one of a variety of alignments to be achieved around the interoperable production and consumption of ODF documents in packages.]



> 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: spec-odf-11
>            Reporter: Bart Hanssens
>
> 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