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: Proposal: Version Identification at the Feature Level

I notice that there are changes in substance among the features of ODF, especially with additions and changes being considered for ODF 1.2.


I believe we should consider a version-identification scheme within the specification that identifies when a provision entered ODF and when a provision's status or description last had any material (non-editorial) change.

It would take some effort to introduce such information for the first time, but I think the sooner this is done the better.  Also, because of the major reorganization in ODF 1.2, this would be extremely useful to implementers, those interested in interchange agreements, and those wanting an easy way to determine what has been changed or added.


In the section where a feature is described, two version numbers are provided, one for the ODF edition when the feature was introduced, one for the latest ODF version in which the status changed (default is when the feature was introduced).

Ideally, the feature level is that of specific attribute usage (understanding that the same name of attribute can have different usages based on the element where the attribute can occur).

The next level is the element.  We need an approach around what changes in attributes and content (including contained elements) constitute a change at the element level.  

Straw Straw Man: I think for elements, version-impacting changes should be ones where required attributes are added or removed and where optional attributes have defaults that are different than before the attribute was introduced for the element.  Subordinate elements should be considered impacting the element on the same basis.  Other changes to the element's attributes and subordinate elements are tracked at those levels.

SIMPLIFICATION: We could simplify this by allowing ODF 1.0 feature-introduction to be assumed by default, not having to be more-specific for any of those until a substantial change to the feature is introduced.  Likewise, the OpenFormula volume could have its feature versions defaulted at the ODF 1.2 level.


It is important to have a way for developers and others to be able to determine what's new and different at the feature level.  It is also valuable for developers and those concerned with interchange arrangements to understand what might be involved in supporting legacy ODF documents and legacy features (some of which may have been deprecated or changed in later versions of the ODF specification).

I've noticed for some time how valuable the feature-level version information is for the Java API.  The Java specifications identify the version in which each API element was introduced.  Adopting a similar device seems important in bringing attention to the introduction of changes.  Using a pair of version numbers seems appropriate so long as material changes, such as deprecation, can occur to previously-specified features.  

This is also valuable in the maintenance and review of the specifications.  Although editorial work is involved, the only way to minimize it, if done at all, is sooner rather than later.

 - Dennis

Dennis E. Hamilton
NuovoDoc: Design for Document System Interoperability 
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]