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-3740) ODF 1.2 Requiring <manifest:manifest> manifest:version breaks downlevel and early 1.2 implementations

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

Dennis Hamilton commented on OFFICE-3740:

@orw Thanks for the background.

I think there is another factor that ap-plies here.

Part 3 is about Package as an independent arrangement that can be used for a variety of applications, not exclusively the packaging of conformant ODF documents.

The dependence for conformant packages is not about whether or not it is an ODF document, but about other things.  For example, the definition of an extended package has to do with additional material on the META-INF/... path.  

The only tie-in to specific usage for ODF has to do with essentially two cases: What the mimetype is, and what the <manifest:file-entry> for manifest:full-path="/" says about the mime type and also the (optional) manifest:version on that element.

I agree that the ODF ocnformance requirements (in Part 1) might want to say more about the presence of manifest:version information on the various components of the package, including content.xml, embedded documents within the main document, etc., but that should be solved in the conformance requirements on documents, not the package.

It seems to me that using the manifest:version on <manifest:manifest> as a quick way of deciding how and whether to accept the document (rather than the package) should not be confused with this. That should be about whether there is something in the package that requires it be understood against the ODF 1.2 specification for packages or not.  I think this should not be so brittle.  

PS: It strikes me that the rules for foreign elements and attributes do not apply to the META-INF/manifest.xml.  There has never been any statement that says the manifest.xml schema has such extension characteristics.  That is even more pronounced in ODF 1.2 because Part 3 is now so separate from Part 1.  So a "must-understand" case for <manifest:manifest> manifst:version is a valuable way to warn an implementation that there is something essential in the package manifest that arrives in ODF 1.2 and the implementation needs to handle.  An example would be the extended encryption cases that do not exist in ODF 1.0/1.1.  But I thiink requirements on the document conformance, rather than package conformance, should not be collapsed together.

> ODF 1.2 Requiring <manifest:manifest> manifest:version breaks downlevel and early 1.2 implementations
> --------------------------------------------------------------------------------------------------------------
>                 Key: OFFICE-3740
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3740
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>    Affects Versions: ODF 1.2
>         Environment: This defect applies to ODF 1.2 Part 3 since Committee Specification 01.
>            Reporter: Dennis Hamilton
>             Fix For: ODF 1.2 Errata 01
> In ODF 1.2-3, the manifest:version="1.2" attribute is mandatory on <manifest:manifest> elements.  This attribute provision was introduced in ODF 1.2.  There were no manifest:version attributes for the <manifest:manifest> attribute in ODF 1.0 and ODF 1.1.
> The presence of this attribute prevents ODF 1.1 and earlier implementations that expect strict honoring of older <manifest:manifest> schemas from accepting ODF 1.2 documents for potential down-level acceptability.
> In addition, documents identified as ODF 1.2 documents produced before the provision was added to the ODF 1.2 specification will now be declared as non-conforming by document validators.
> The Catch 22 consists of the fact that expecting the attribute will invalidate previous documents that were identified as ODF 1.2 documents and that producing the attribute will cause error messages (at least) in down-level use of documents that may well have no specific dependency on material ODF 1.2 provisions whatsoever. 
> The provision is too brittle and causes more problems without solving very many.

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]