OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Thoughts on ODF-Next

Hi Andreas,

Andreas J. Guelzow wrote:

> While I realize that we can't mandate that and in fact have no control
> over whether a vendor calls their format ODF1.3 or whatever, I thin kwe

A CSD approval is the first level of approval in the OASIS TC process.
So, if we approve an ODF 1.3 draft as CSD, and if an implementor 
implements this CSD, why shouldn't that be called ODF 1.3? How would you 
call it instead?

> at least should not encourage that behaviour as suggested.

To which suggestion do you refer? My initial proposal neither contains
the term "encourage", nor "recommend".

All I was suggesting in the first place was that vendors, instead of
implementing extensions to ODF in foreign namespaces, take them to the
TC as proposals, discuss them there, ask for an approval, and implement
what has been agreed in the TC when this has reached CSD level. Please
note that this is no unconditional recommendation to implement CSD. It
is also neither a recommendation to implement extensions, or to use all
features in their products immediately when they reached CSD level.

What do you think is wrong with this? Do you think it is better if every
vendor has its own set of extensions?

What was also discussed in this thread was whether we should encourage
vendors in general to implement CSDs. This was not subject of my initial 
suggestions. But when the OASIS TC process requests statements of use 
from OASIS members, it clearly encourages TC members to implement the 
specification a TC produces before they reached the OASIS standard 
approval. That is the case regardless whether we as TC encourage TC 
members to implement CSDs. It's part of the process, and I personally 
think that this is good. Because to get feedback from implementors 
before a standard is approved is of course much better than repairing a 
standard after it has been approved.

Best regards


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]