[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: FW: [office] Discussion Requested - Version Identification at theFeature Level
On 10/13/08 20:38, robert_weir@us.ibm.com wrote: > 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 Sounds like a good idea. This information would be informative. For this reason, I would prefer a solution that keeps the information separate from the normative text. > words, list all of the section/subsection numbers along with what version > ODF introduced or substantially changed that feature. Some time ago I have developed an XSLT style sheet that lists the elements, attributes and attribute values of an ODF schema in a spreadsheet[1]. One could apply this style sheet to the ODF 1.1 schema and the ODF 1.2 schema. The result would be one sheet that summarized the elements and attributes of ODF 1.1, and another one that summarizes those of ODF 1.2. I'm not a spreadsheet expert, but believe it should be possible to compare these two so that one gets a table which for each element and attributes states whether the element or attribute is new, or whether its value changed. Since the table representation of spreadsheet and text document does not differ, one could simply copy the spreadsheet data into the ODF specification itself as an appendix. Well, it should also be possible to do the comparison by XSLT itself, but I don't have something for this at the moment. One does not get all changes we made to ODF 1.2 this way, but I believe most of them. In any case, using this as a start seems to be much easier than collecting the information manually. > > The assumption is that new features are introduced into new subsections. > This may be a bad assumption. Thanks to the changes that Patrick made, this assumption is actually correct. Each element is described in a subsection of its own, and the same applies to attributes. With the generation of the element and attribute lists I have further introduces a simple pattern for reference marks. This makes it easy to add reference to the subsection where an element or attribute is defined. Michael > > -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 >> > > > --------------------------------------------------------------------- > 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 > -- Michael Brauer, Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems GmbH Nagelsweg 55 D-20097 Hamburg, Germany michael.brauer@sun.com http://sun.com/staroffice +49 40 23646 500 http://blogs.sun.com/GullFOSS Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]