Re: [office] Thoughts on ODF-Next

[Michael Brauer <michael.brauer@oracle.com>]

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