Re: [office] Thoughts on ODF-Next

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

Hi Andreas,

On 14.01.2011 01:41, Andreas J. Guelzow wrote:

1294965701.28702.0.camel@localhost" type="cite">

On Thu, 2011-01-13 at 10:52 -0700, robert_weir@us.ibm.com wrote:
  

I wonder if the impact of the problem would be reduced if we can turn 
around standards faster?  In other words, would it be more tolerable if a 
vendor implements a draft 6 months before the standard is finally approved 
compared to implementing it 2 years before approval?  I think that is 
something we have more direct control over.

    

The problem I have is when a vendor implements a certain feature from a
draft and the specification is found wanting. Obviously there would be
some reluctance to change a specification in a incompatible way to that
implementation. So implementing a feature from a draft can have the
effect of cutting off any improvements to that feature.
  

1294965701.28702.0.camel@localhost" type="cite">

Now if the feature were implemented using foreign elements no such
problem would exist and if the spec does not change it would be trivial
to change the element name/namespace to match the approved standard.
  

I understand your concern, but I think neither implementing CD features in foreign namespaces only nor implementing them only after the approval as an OASIS standard solves this issue (if it does exist at all).

Take for example the surface charts or text rotation, where it turned out that different interpretations of the specification did exist only after the feature was in an OASIS standard. If we would have implemented these features in committee drafts, then where would have been good chances that we figured this out before the OASIS standard approval, and could have made the necessary corrections easily in the specification and the implementations. This would have been much easier than resolving the issue in approved OASIS standard, because it is of course easier to change a feature in a CD than it is to to change it in an OS. Further, the number of documents that use a feature is lower in the CD stage than it is in the OS stage. So, the general impact of change to a feature that is only in a CD is lower. Implementing features early then they are in CD state has some real advantages for the quality and consistency of a an OS.

These advantages do not exist if we use foreign namespaces. We may then have multiple implementations as well, but they are not interoperable, because it is unlikely that multiple implementations use the same foreign namespaces. So, we don't win anything by that. But we may run into problems explaining users that they can't exchange their documents.

Further, if a feature needs to be changed in an incompatible way, the impact of this change does not depend on the namespace. The main problem here are existing implementations that are not aware of the change. The problems these implementations have with document created by newer applications are the same, regardless which namespace has been used.

Best regards

Michael

1294965701.28702.0.camel@localhost" type="cite">

Andreas  
  

--

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