Re: [office] Thoughts on ODF-Next

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

Hi,

On 18.01.2011 15:34, robert_weir@us.ibm.com wrote:

OFCF1A322A.C804264B-ON8525781C.004CFCBF-8525781C.004FB36D@lotus.com" type="cite">

<thorsten.zachmann@nokia.com> wrote on 01/18/2011 03:43:28 AM:

  

There is one thing which needs thinking. If a vendor implements a 
feature as described in a CSD and releases the software using the 
features there will be documents which use that feature. When then 
later the feature is changed in a incompatible way applications that
don't support the CSD will not be able to show the document 
correctly which is very bad for interoperability.

What do others think about that?

    

This is true.  But the alternative proposals are also poor for 
interoperability, such as using a non-ODF namespace. The real problem is 
when an implementation writes a document that does not conform to 
non-extended ODF.  Whether this is done by vendor extensions, or by 
implementation of a draft version of ODF that then changes, or due to a 
bug, or whatever, the effect is the same.  If you are writing out markup 
that others do not understand, or which they understand differently, than 
you have this problem. 
  

I agree. Another alternative would be to not implement CSDs at all. But that's also poor for interoperability, because we then will notice interoperability issues between applications, regardless what caused it, only after the approval as OASIS standard. It is when much more difficult to correct them than it is if a specification is in CSD state. Having interop issues in CSD implementations for sure isn't good, but having them in an OASIS standard is worse.

OFCF1A322A.C804264B-ON8525781C.004CFCBF-8525781C.004FB36D@lotus.com" type="cite">

No amount of syntactic sugar around version attributes will solve this 
problem. 

But one way approach to dealing with this issue is to raise the bar for 
what gets into an approved CSD. In other words, give it sufficient 
scrutiny so that we have high confidence that once a CSD has been approved 
that the feature will not change in major ways.  I'm not speaking 
absolutes, but a commitment that we will not approve a feature 
unless/until we have a high level of confidence.
  

I agree, and I think that's a very good point. It is us, the ODF TC, who develops ODF. We control ODF. If we think a proposal is questionable or details are missing, then we don't have to accept that.

Actually, we have already a (relative) high bar for the integration proposals, when we say that only proposal that are detailed enough that they can be integrated into the specification.shall be approved. This is a prerequisite to determine that enough details are present so that the proposal can be implemented in an unambiguous way,

OFCF1A322A.C804264B-ON8525781C.004CFCBF-8525781C.004FB36D@lotus.com" type="cite">

In other words:

1) We have no control over what vendors implement and when they implement 
it and what they call it.
  

Right. But we can and must assume that vendors that implement ODF are interested in interoperable implementations.

OFCF1A322A.C804264B-ON8525781C.004CFCBF-8525781C.004FB36D@lotus.com" type="cite">

2) Merely renaming things is obviously syntactic sugar and has no real 
effect

3) The only thing we as a TC control is the contents of a specification 
and whether it is approved as a CSD.

So I suggest that we apply ourselves to where we have the most direct 
influence.
  

I agree

Michael

OFCF1A322A.C804264B-ON8525781C.004CFCBF-8525781C.004FB36D@lotus.com" type="cite">

-Rob

---------------------------------------------------------------------
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 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