Re: [office] Thoughts on ODF-Next

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

Hi Dennis,

On 14.01.2011 03:07, Dennis E. Hamilton wrote:

The problem that concerns me has to do with the potential ambiguity in the use of namespaces in combination with version numbers when those are only provisional prior to the ratification of an OASIS Standard.  (I would hope they not be very provisional by the time a Candidate Standard Public Review is undertaken, since the specification has to be complete for the review, but even then there could be a reset.  Still, it seems wise to-risk manage this by how provisional features are reported out as considered stable enough to use.)
  

I think I've said this before, but the CSD we approve should of course be in a good and consistent state. We as the TC should think that they are good enough to be reviewed and implemented. Substantial changes to a specification as result of a public review should be the exception. This actually should be much easier to achieve if we have a sequence of CSDs which all have one a limited amount of changes, than it is to have a CSD which contains the development work of let's say two years or so.

Further, the OASIS process requires statements of use before an OASIS standard ballot can be started. So, implementations of the specification before their approval as an OASIS standard is clearly encouraged even be the OASIS process.

You are of course right that their are risks of implementing CDs for vendors, and it may indeed be wise to at least wait until the public review of a feature. But I think vendors are well aware of this, and they can handle this.

I can even see the need to deprecate or even completely remove an element name or attribute name (presumably for a new feature but who knows) in order to make a differently-named replacement in the same namespace and ODF version.  I think this matters especially if a Public Review (or even a PAS submission balloting) leads to a breaking change to what is presumably implemented. 

In the case that implementers are encouraged to support provisional features established in a CSD, they need some clean way to migrate in the case a provision is revised and there are products and documents relying on the draft form in the wild.  
  

If  "implementers are encouraged to support provisional features established in a CSD" is what you read from my suggestions then your are interpreting to much into it (or I was unclear). We of course should encourage vendors to start implementing specifications before they are approved as OASIS standards, because we can only benefit from the experience they make. But we should never raise the expectation that a CSD is the same as an OS, or that it is as safe to implement a CSD than it is to implement an OS. That is clearly not the case. A CSD is a CSD, and an OS is an OS.

What I wrote in my original mail was: "Vendors may implement CSDs instead of extended conforming documents with vendor specific extensions." And this is exactly what I meant. There are situations where a vendor cannot wait for the next OS before a feature gets implemented. And in these cases, I encourage vendors to take their request to the TC, to discuss it there, and to implement what is the result of the discussion (which  can be found in the next CSD) rather than to implement extensions that maybe never are taken to the TC. That's it. Not more, but also not less.

I think that the TC needs to consider migration more thoroughly when an existing provision is materially modified (e.g., to be contradictory and/or down-level confusing) in a subsequent version of the OASIS Standard as well.  We might be wise to introduce a newly-named version and deprecate the previous one so that it is absolutely clear what we are doing and how implementations need to prepare for migration and/or down-level soft failure.

There could be provisional intermediate version numbers, of course (e.g., "1.2-bis1", That might be appropriate regardless, although its standing would be weird.  E.g., ODF 1.3 might have to define the provisional numbers sufficient to declaring their deprecation.  Seems a little weird.
  

I would be careful with such things. A CSD is a CSD, but not an OS. We should not give them more weight than they have. We should encourage vendors to implement CSD so that we get early feedback. We should encourage them to implement CSD rather than proprietary extensions where they cannot wait for the next OS. But we should also make clear that a CSD is not an OS, and what they implement CSDs on their own risk.

Best regards

Michael

--

Michael Brauer | Oracle Office Development
Phone: +49 40 23646 500 | |
Oracle Office Global Business Unit

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

Oracle is committed to developing practices and products that help protect the environment