[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Thoughts on ODF-Next
Hi Dennis, Dennis E. Hamilton wrote: > Michael, thank you for your thoughts on the future process for further > development of the feature set of the OASIS ODF Standard. I have one > objection. > > First, have a happy holiday season with the joyful satisfaction of knowing > that the CD06 Public Review has actually commenced. > > In short: I object to any introduction of speculative features by premature > appropriation of the ODF x.y schemas and namespaces without any version > control and without the full application of the standards-development > process. > > - Dennis > > More thoughts: > > To suggest to implementers that a CSD that has never seen Public Review is > safe to implement strikes me as ridiculous. It also creates a distorted > preferential access to the ODF x.y schemas and namespaces that seems > incompatible with any claim to an open-standards process. First of all, let me clarify that I'm not recommending to implement CSDs in favor of approved standards. Whenever a vendor decides to implement a CSD in an application, that application of course should also support the approved ODF standards. But I think we should encourage vendors to implement CSDs, since this gives us early feedback to our specifications, and therefore helps to improve the ODF OASIS standard. And early experiences with a specification are part of the OASIS standardization process when it request statements of use. And what could be a better use of a specification than trying to implement it? But I understand your concern. Of course, before a feature gets implemented, it should be stable enough to be implemented. So, I maybe should have been clearer, but the CSD's I'm thinking of should be as stable as possible. That is, the new features they contain should have been discussed and agreed in the TC. And we as TC should be of the opinion that the CSDs are good enough to become an OASIS standard if we wish so. That's why I suggest to have development phases of 4 months, followed by editing ans stabilization phases of 2 months. I'm definitively not thinking of approving working drafts as CSD after 6 months, regardless in which shape they are. And of course it may be a good idea to wait for a subsequent public review before implementing a feature. > > The potential for a versioning disaster in the schemas and namespaces seems > to be an unnecessary risk. I also think that it subverts what it means to > be "standard" in the open-standards sense as well as the senses used by > Standards Development Organizations that have independent interoperable > implementation as a focus. I also think that it can lead to unfortunate > baggage because of the inertial affect (and justification) that the CSD has > been implemented, whatever its quality is finally judged to be. I don't see > how any governmental agency, for example, would write procurement > specifications that named or even tolerated CSD-defined speculative > features. Certainly no other specification can make normative use of them. My suggestion to implement CSDs you quote below is not a general suggestion to implement CSDs, but is related to the case where a vendor needs a particular feature in ODF documents, and can't wait for the next OASIS standard. Right now, the only option is to implement this as extension. Such extensions are not interoperable , they can't be used in procurement, and either cannot be normatively referenced. I think it is preferable if such features are taken to the TC early where they can be discussed and agreed to be added to the next ODF specification. And of course, if a vendor decides to implement a CSD, it does so on its own risk. > I suggest that something to work on first, perhaps in OIC too, is the > identification of practices for extensions on the ODF 1.2 base that are safe > in the face of eventual incorporation into ODF x.y (and not) and guidance in > how implementations can consistently treat extensions as unrecognized > foreign features so there is a good level of predictability and stability, > even in the presence of extensions (recognized or not). This is not unlike > guidance for implementations that selectively implement a subset of the > already-standard features too and we could all use consistency in that > regard. I have no objections to improve ODF's extension mechanisms if we receive a proposal for this, but I have no idea how long this would take. So, my suggestion would be that if there is enough interest in this, we work on that in parallel to the many feature request we have in the loop. If an extension proposal is a simple task we will have a proposal very soon, and we may (if reasonable) apply it also to feature we did already finish by when. And if it is longer task, we anyway would be able to deliver a new CSD in 6 months. Given the amount of proposals we have in the loop, I would like to avoid that we spend significant time on extension mechanism before we are able to integrate new proposals. Best regards Michael > > > -----Original Message----- > From: Michael Brauer [mailto:michael.brauer@oracle.com] > Sent: Friday, December 17, 2010 05:03 > To: OpenDocument Mailing List > Subject: [office] Thoughts on ODF-Next > > [ ... ] > > Where are a lot of advantages this model has compared to the one we used > for ODF 1.2: > > - Enhancements and new features are available on CSD level in less than > 6 months. > - Vendors may implement CSDs instead of extended conforming documents > with vendor specific extensions. This > -- provides a higher level of interoperability between ODF > implementations that go beyond the last approved OASIS standard > -- provides transparency to users > [ ... ] > > Best regards, and best wishes for the holiday season. > > Michael > > [ ... ] > > > --------------------------------------------------------------------- > 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 | Oracle Office Development Phone: +49 40 23646 500 Oracle Office GBU ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]