Re: FW: [office] Discussion Requested - Version Identification at theFeature Level

[robert_weir@us.ibm.com]

I agree that this would be useful to have.   I wonder if we could do 
something like what we have in Appendix D 'Core Feature Sets' ?  In other 
words, list all of the section/subsection numbers along with what version 
ODF introduced or substantially changed that feature.

The assumption is that new features are introduced into new subsections. 
This may be a bad assumption.

-Rob

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 10/13/2008 
11:50:54 AM:
> 
> I request discussion of this proposal on the next (October 20) TC 
> Coordination Call 
> 
> If there are other things I should do beyond making the proposal in 
> e-mail (Wiki, document storage), please let me know and I will do 
> that also.  It is time I learned.
> 
>  - Dennis
> 
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
> http://lists.oasis-open.org/archives/office/200809/msg00114.html
> Sent: Monday, September 29, 2008 09:35
> To: ODF TC List
> Subject: [office] 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.
> 
> OBJECTIVE
> 
> 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.
> 
> STRAW MAN
> 
> 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.
> 
> FURTHER DISCUSSION 
> 
> 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 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>