[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (OIC-5) Plugfest, subpackages (chartin spreadsheet)
[ http://tools.oasis-open.org/issues/browse/OIC-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Svante Schubert updated OIC-5:
-------------------------------
Regarding different usage of relative URI in ODF:
========================================
I believe we all agree that we can normalice normalize relative URLs on document XML level in ODF 1.2
On document level ODF implementations write out different URLs for the same referenced object:
For instnace different @href values might indeed correctly reference to the same object as "./Object 1", "Object 1", "Object 1/", "./Object 1/" (even many more variations as "./Object 1/./././" are possible - if I interpret http://www.apps.ietf.org/rfc/rfc3986.html#sec-3.3 correctly).
If we would limit our document URL encoding, we would force any File Format Transformation (like XHTML to ODF) to verify the value of attributes containing URLs (e.g. the @href attribute), creating an ODF relative URL subset.
If the problem is only triggered by ODF XML comparison this URL normalization can be part of the ODF normalization before comparison. Still a best practice advice (the result of a normalization) might be given.
On the other hand, if we are talking about the Package level, there are different requirements:
Here the relative paths within manifest's full-path attribute is often usually used by an ODF implementation as unique key for a package file a normalized encoding might be useful and even recommended to prevent a potential harmful "../../../../../.bash". In the end we would remove substring as "/./" "/../" and "//" and prefixes as "./" "../".
The ZIP Note ODF 1.2 is referencing to
http://www.pkware.com/documents/APPNOTE/APPNOTE_6.2.0.txt
is unfortunately not specifying the term "relative path" any further (not even an RFC is referenced).
Before moving this issue to the ODF 1.2 TC, I would suggest to ask a comment from PKWARE, why not using normalized paths (and referencing for relatives path http://www.apps.ietf.org/rfc/rfc3987.html#sec-6.5 )
PS: We might ask as well to refer to ODF aside of OOXML in http://www.pkware.com/support/application-note-archives
Regarding subdocument in ODF:
===========================
Every directory in the manifest with a mimetype is a document within the package. For instance OpenOffice creates directory with configuration files, which have a MIME type and are therefore Package documents.
This is indeed a matter we should raise in the ODF TC. Especially as I did a proposal about two years ago in the context of metadata that tried to explain the entity of a document on Package layer level:
See http://wiki.oasis-open.org/office/Change_Proposal_for_ODF_1.2_Metadata_according_Embedded_Document_Scenario?highlight=(CategoryApprovedProposal\b)|(CategoryCategory\b)#RequestedchangestotheODFStandard
Svante
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]