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) 4.8.14.2 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=31680#action_31680 ] 

Dennis Hamilton commented on OFFICE-3740:
-----------------------------------------

@Andreas,

I agree that speculative upgrade to ODF 1.2 before the specification was baked was dangerous.  

Although that accounts for there being all of these variations in the wild, they are now in the wild and the documents that originated with them are there too.  I don't think it is fair to penalize users for this.

Also, I think it is important to understand that the breaking case is with regard to down-level consumers that were not implemented based on any speculation whatsoever.  That is the focus of my attention with regard to this specific issue.  This is the oversight that was made when <manifest:manifest> manifest:version was introduced and made mandatory.  It just didn't receive the analysis that has since arisen out of hind-sight and recognition of what all the cases in the wild have turned out to be.  Instead of fostering interoperability, the outcome has been a reduction of interoperability.  It appears, in fact, that the attribute is consistently ignored on consumption by those processors that produce it and also many that don't produce it.

More generally, I think the discussion on the list concerning ways to have provisional implementations (not using ODF-official namespaces) that are for features with reserved definitions in future releases of ODF is important.  This would have made the handling of implementation-specific digital signature extensions in ODF 1.1 documents more transparent and it will help with anticipated features for ODF 1.3 that are related to document privacy and integrity.  

Downlevel disruption, even among implementations of the same ODF version, will still happen, of course.  (One case now in existence is the change of what encryption is used by default, causing older implementations to fail.  In this case, <manifest:manifest> manifest:version="1.2" has been no help because it was being produced either way.  Although that ends up relying on published standards, the result is not necessarily more secure.  The down-level behavior is quite marvelous.)

> 4.8.14.2 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
>            Assignee: Patrick Durusau
>             Fix For: ODF 1.2 Errata 01
>
>
> In ODF 1.2-3 4.8.14.2, 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]