OASIS Open Document Format for Office Applications (OpenDocument) TC

Dear TC members,

while we are waiting for the ODF 1.2 public review, I think it may be a
good time to share a few thoughts how I could imagine that we adapt our
specification process and schedule for future ODF versions to deliver
specifications more frequently, and how to lower the time from a first
feature proposal to a specification that contains the feature.

I don't want to start with too many introductory words, but think a few
observation may be reasonable, in particular for those who are new in
the TC:

- The OASIS TC process defines three levels of approval: Committee
Specification Drafts (CSD), Committee Specifications (CS), and OASIS
standards. While it of course should the objective of a TC to get
OASIS standard approvals for the specifications it develops, a TC may
decide to advance a particular specification only to the CSD or CS level.
- It takes a minimum of about two months to advance a CSD to a CS, and
a minimum of about three months to advance a CS to an OASIS standard.
- There is an obligation to submit all ODF OASIS standards to ISO. The
ISO standardization process itself takes at least 6 months.
- Each specification document requires editorial work (including
clarifying last details and issues). A rough estimate could be that for
two months specification work, 1 month editorial work is required.
- Our TC process is member driven: Individual TC members may propose
enhancements for ODF, but they are also responsible for advancing their
proposals into a state where enough details are specified so that the
proposals can be voted on and integrated into the specification by the
TC editors. Which means that it is to a large degree under the control
of the TC members themselves when an enhancement is ready to be
considered for integration into the ODF specification.

Considering all this, it is realistic to assume that we cannot release
OASIS standards more frequently than every two years, but even when we 
would only have a window of about 6 months where we can add enhancements 
into a specification document.

What I'm therefore suggesting is that we

a) make use of the CSD and CS levels of approval
b) adopt a time-boxed or "train model" where we have previously agreed
dates where we aim to have CSDs ready, and where we accept for a CSD
only what is ready by when.
c) decide for each CSD individually whether we want to get a higher 
level of approval or public reviews.

How could this look like in practice?

We may agree that we deliver CSDs every 6 months. This would mean that 
we would have a phase of 4 months open development where we integrate 
all proposals that are ready to be integrated, which means that they are 
detailed enough to be integrated and have been approved. After this 4 
months, we would have a phase of two months where the proposals get 
integrated into the draft. We when vote on the draft, and most likely 
get a CSD that is published. After the CSD approval, we start working on 
the next CSD in the same way.

When a CSD has been approved, we also discuss and agree whether we want 
to start a 30-day public review for the draft, and ask for approval as a
CS. But even if we do so, we would continue our work on the next CSD.

Where are a lot of things to consider for this decision: For instance
how much new content we have in the specification. Or whether we have
other public reviews running. Or where we are in the approval process of
previous specifications. For this reason, it appears reasonable to not
set up any rules for this in advance, but to just use the CSD approvals
as checkpoints, and to decide individually for each CSD how to proceed.

When we decide to advance a CSD to a CS and got the CS approval, we
would then discuss and decide whether want to advance it to an OASIS
standard.

Where may of course be features that need more than four months to be
developed. For these, we may set up sub committees, and may consider the
deliverable of the sub committee as a proposal that we treat the same
way as the other proposals.

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
- The "rush hour" we get when we are getting closer to the end of a
feature definition phase is avoided, because if a proposal misses a 
specific CSD, the next opportunity is already 6 months later.
- Assuming that we get comments in particular for new features, we get a
better distribution of comments by having many "small" public reviews 
rather than a single "large" public review.

Feedback to these suggestions is of course very welcome. I also did 
present these ideas at the last OOoCon. The feedback I got there from 
users of the ODF specification was positive. The slides of the 
presentation are available here:

http://www.ooocon.org/index.php/ooocon/2010/paper/view/233

Best regards, and best wishes for the holiday season.

Michael

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

Michael,

On the whole I very much like the proposed schedule, although I would
use the more frequent CSD periods to incorporate comments from national
bodies.

Given the changes in OASIS process, I suspect new agreements will need
to be made between JTC1 and OASIS.

I would not use the CSD status as a means to allow the implemented OASIS
specifications to get out of synch with the ISO version.
 
For several reasons:

First, as you will recall, having ISO status is important in a number of
marketing venues. 

Second, we have gone to a great deal of effort to not only secure that
status for current versions and to arrange for it to remain current.

Third, having both OASIS and ISO review means that a broader community
has feedback into ODF, making it a much stronger standard.

With that minor tweaks, I like your proposal very much!

The six month window is doable and will make it easier to get promise
prospective users when new capabilities are likely to appear. (I have
been telling people about the metadata for quiet some time.)

Hope you are looking forward to a great holiday season!

Patrick

On Fri, 2010-12-17 at 14:03 +0100, Michael Brauer wrote:
> Dear TC members,
> 
> while we are waiting for the ODF 1.2 public review, I think it may be a
> good time to share a few thoughts how I could imagine that we adapt our
> specification process and schedule for future ODF versions to deliver
> specifications more frequently, and how to lower the time from a first
> feature proposal to a specification that contains the feature.
> 
> I don't want to start with too many introductory words, but think a few
> observation may be reasonable, in particular for those who are new in
> the TC:
> 
> - The OASIS TC process defines three levels of approval: Committee
> Specification Drafts (CSD), Committee Specifications (CS), and OASIS
> standards. While it of course should the objective of a TC to get
> OASIS standard approvals for the specifications it develops, a TC may
> decide to advance a particular specification only to the CSD or CS level.
> - It takes a minimum of about two months to advance a CSD to a CS, and
> a minimum of about three months to advance a CS to an OASIS standard.
> - There is an obligation to submit all ODF OASIS standards to ISO. The
> ISO standardization process itself takes at least 6 months.
> - Each specification document requires editorial work (including
> clarifying last details and issues). A rough estimate could be that for
> two months specification work, 1 month editorial work is required.
> - Our TC process is member driven: Individual TC members may propose
> enhancements for ODF, but they are also responsible for advancing their
> proposals into a state where enough details are specified so that the
> proposals can be voted on and integrated into the specification by the
> TC editors. Which means that it is to a large degree under the control
> of the TC members themselves when an enhancement is ready to be
> considered for integration into the ODF specification.
> 
> Considering all this, it is realistic to assume that we cannot release
> OASIS standards more frequently than every two years, but even when we 
> would only have a window of about 6 months where we can add enhancements 
> into a specification document.
> 
> What I'm therefore suggesting is that we
> 
> a) make use of the CSD and CS levels of approval
> b) adopt a time-boxed or "train model" where we have previously agreed
> dates where we aim to have CSDs ready, and where we accept for a CSD
> only what is ready by when.
> c) decide for each CSD individually whether we want to get a higher 
> level of approval or public reviews.
> 
> How could this look like in practice?
> 
> We may agree that we deliver CSDs every 6 months. This would mean that 
> we would have a phase of 4 months open development where we integrate 
> all proposals that are ready to be integrated, which means that they are 
> detailed enough to be integrated and have been approved. After this 4 
> months, we would have a phase of two months where the proposals get 
> integrated into the draft. We when vote on the draft, and most likely 
> get a CSD that is published. After the CSD approval, we start working on 
> the next CSD in the same way.
> 
> When a CSD has been approved, we also discuss and agree whether we want 
> to start a 30-day public review for the draft, and ask for approval as a
> CS. But even if we do so, we would continue our work on the next CSD.
> 
> Where are a lot of things to consider for this decision: For instance
> how much new content we have in the specification. Or whether we have
> other public reviews running. Or where we are in the approval process of
> previous specifications. For this reason, it appears reasonable to not
> set up any rules for this in advance, but to just use the CSD approvals
> as checkpoints, and to decide individually for each CSD how to proceed.
> 
> When we decide to advance a CSD to a CS and got the CS approval, we
> would then discuss and decide whether want to advance it to an OASIS
> standard.
> 
> Where may of course be features that need more than four months to be
> developed. For these, we may set up sub committees, and may consider the
> deliverable of the sub committee as a proposal that we treat the same
> way as the other proposals.
> 
> 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
> - The "rush hour" we get when we are getting closer to the end of a
> feature definition phase is avoided, because if a proposal misses a 
> specific CSD, the next opportunity is already 6 months later.
> - Assuming that we get comments in particular for new features, we get a
> better distribution of comments by having many "small" public reviews 
> rather than a single "large" public review.
> 
> Feedback to these suggestions is of course very welcome. I also did 
> present these ideas at the last OOoCon. The feedback I got there from 
> users of the ODF specification was positive. The slides of the 
> presentation are available here:
> 
> http://www.ooocon.org/index.php/ooocon/2010/paper/view/233
> 
> Best regards, and best wishes for the holiday season.
> 
> Michael
> 

Patrick Durusau 

I think there is another matter of importance to recognize here.

The production of CSDs is cumulative, not modular.  That is, every CSD that
is produced has to incorporate the (current form) of features in previous
drafts and be for all four parts of ODF x.y assuming the ODF 1.2 structure
is maintained.

Furthermore, the cumulative (or even incremental-only) change tracking would
become nightmarish since, presumably, each CSD in the track model would
incorporate entire new features.  

I'm not sure how the subsequent public reviews in such a situation could be
reduced to 15 days, if we are grafting in feature modules at each cut.

Perhaps one might do effected parts only in some Public Reviews, but at some
point we are back to having to do a full review series to put a set of
drafts on the Committee Specification and Standard track.

Maybe we need to take another look at modularization with supplements as
well as the handling of extensions and the prospective movement of
extensions from practice to standard.

 - Dennis



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Friday, December 17, 2010 10:27
To: Patrick Durusau
Cc: Michael Brauer; OpenDocument Mailing List
Subject: Re: [office] Thoughts on ODF-Next

[ ... ]

On the other hand, a CSD/Public review does have overhead, both in the 
length of the review, but also on the administrative checks.  Since the 
initial review is the longer review (30-days), there is an advantage to 
doing that as early as possible, to get that out of the way.  Of course, 
once you've done that you have the burden of highlighting changes in 
future CSDs.  But on balance I think we're better of to have a CSD/public 
review early.

[ ... ] 

"Dennis E. Hamilton" 

Rob,

On Fri, 2010-12-17 at 13:26 -0500, robert_weir@us.ibm.com wrote:
> Patrick Durusau 

Patrick Durusau 

Dear ODF TC Co-Chairs,

I will be on my annual winter vacation
from January 1 through 12. As a result, I will not be able to attend TC
meetings on January 3 and January 10, and as a result I will  miss
two consecutive TC meetings,  Since I wish to preserve my voting rights,
I am requesting a Leave of Absence effective January 3 and ending January
12, so that my voting rights resume when I return and attend the TC meeting
of January 17, 2011.


Regards,

Don Harbison
Program Director, IBM ODF Initiative
Tel. +1-978-399-7018
Mobile: +1-978-761-0116
Email: donald_harbison@us.ibm.com

Patrick, On 17.12.2010 14:53, Patrick Durusau wrote: Michael, On the whole I very much like the proposed schedule, although I would use the more frequent CSD periods to incorporate comments from national bodies. Yes, that's good idea. Our experience is that we get comments from SC34 mostly while we conduct public reviews. So, having more CSDs and more public review may also allow us to incorporate more comments from nation bodies. In particular, we may receive these comments earlier then we would if we have only one large public review at the end of the development processes. This makes it easier to integrate the feedback. Given the changes in OASIS process, I suspect new agreements will need to be made between JTC1 and OASIS. I would not use the CSD status as a means to allow the implemented OASIS specifications to get out of synch with the ISO version. That is not my intention. The intention is only to have more intermediate drafts. But of course these drafts will only be in advance to the most recent ISO standard (as well as to the most recent OASIS standard). But that should not be an issue. Best regards Michael For several reasons: First, as you will recall, having ISO status is important in a number of marketing venues. Second, we have gone to a great deal of effort to not only secure that status for current versions and to arrange for it to remain current. Third, having both OASIS and ISO review means that a broader community has feedback into ODF, making it a much stronger standard. With that minor tweaks, I like your proposal very much! The six month window is doable and will make it easier to get promise prospective users when new capabilities are likely to appear. (I have been telling people about the metadata for quiet some time.) Hope you are looking forward to a great holiday season! Patrick On Fri, 2010-12-17 at 14:03 +0100, Michael Brauer wrote: Dear TC members, while we are waiting for the ODF 1.2 public review, I think it may be a good time to share a few thoughts how I could imagine that we adapt our specification process and schedule for future ODF versions to deliver specifications more frequently, and how to lower the time from a first feature proposal to a specification that contains the feature. I don't want to start with too many introductory words, but think a few observation may be reasonable, in particular for those who are new in the TC: - The OASIS TC process defines three levels of approval: Committee Specification Drafts (CSD), Committee Specifications (CS), and OASIS standards. While it of course should the objective of a TC to get OASIS standard approvals for the specifications it develops, a TC may decide to advance a particular specification only to the CSD or CS level. - It takes a minimum of about two months to advance a CSD to a CS, and a minimum of about three months to advance a CS to an OASIS standard. - There is an obligation to submit all ODF OASIS standards to ISO. The ISO standardization process itself takes at least 6 months. - Each specification document requires editorial work (including clarifying last details and issues). A rough estimate could be that for two months specification work, 1 month editorial work is required. - Our TC process is member driven: Individual TC members may propose enhancements for ODF, but they are also responsible for advancing their proposals into a state where enough details are specified so that the proposals can be voted on and integrated into the specification by the TC editors. Which means that it is to a large degree under the control of the TC members themselves when an enhancement is ready to be considered for integration into the ODF specification. Considering all this, it is realistic to assume that we cannot release OASIS standards more frequently than every two years, but even when we would only have a window of about 6 months where we can add enhancements into a specification document. What I'm therefore suggesting is that we a) make use of the CSD and CS levels of approval b) adopt a time-boxed or train model where we have previously agreed dates where we aim to have CSDs ready, and where we accept for a CSD only what is ready by when. c) decide for each CSD individually whether we want to get a higher level of approval or public reviews. How could this look like in practice? We may agree that we deliver CSDs every 6 months. This would mean that we would have a phase of 4 months open development where we integrate all proposals that are ready to be integrated, which means that they are detailed enough to be integrated and have been approved. After this 4 months, we would have a phase of two months where the proposals get integrated into the draft. We when vote on the draft, and most likely get a CSD that is published. After the CSD approval, we start working on the next CSD in the same way. When a CSD has been approved, we also discuss and agree whether we want to start a 30-day public review for the draft, and ask for approval as a CS. But even if we do so, we would continue our work on the next CSD. Where are a lot of things to consider for this decision: For instance how much new content we have in the specification. Or whether we have other public reviews running. Or where we are in the approval process of previous specifications. For this reason, it appears reasonable to not set up any rules for this in advance, but to just use the CSD approvals as checkpoints, and to decide individually for each CSD how to proceed. When we decide to advance a CSD to a CS and got the CS approval, we would then discuss and decide whether want to advance it to an OASIS standard. Where may of course be features that need more than four months to be developed. For these, we may set up sub committees, and may consider the deliverable of the sub committee as a proposal that we treat the same way as the other proposals. 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 - The rush hour we get when we are getting closer to the end of a feature definition phase is avoided, because if a proposal misses a specific CSD, the next opportunity is already 6 months later. - Assuming that we get comments in particular for new features, we get a better distribution of comments by having many small public reviews rather than a single large public review. Feedback to these suggestions is of course very welcome. I also did present these ideas at the last OOoCon. The feedback I got there from users of the ODF specification was positive. The slides of the presentation are available here: http://www.ooocon.org/index.php/ooocon/2010/paper/view/233 Best regards, and best wishes for the holiday season. 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

Just my $.02, but I would be careful of this approach since anyone who must follow the ISO path vs the OASIS one would not be able to implement new features/improvements/etc until a new OS submission to JTC1 occurred and was approved. The TC was greatly criticized for not sending v1.1; intentionally avoiding OS approval would, I think, be frowned upon by SC34.

Best regards and best wishes to all for a very happy holiday season,

Mary





On Dec 17, 2010, at 8:03 AM, Michael Brauer wrote:

> Dear TC members,
> 
> while we are waiting for the ODF 1.2 public review, I think it may be a
> good time to share a few thoughts how I could imagine that we adapt our
> specification process and schedule for future ODF versions to deliver
> specifications more frequently, and how to lower the time from a first
> feature proposal to a specification that contains the feature.
> 
> I don't want to start with too many introductory words, but think a few
> observation may be reasonable, in particular for those who are new in
> the TC:
> 
> - The OASIS TC process defines three levels of approval: Committee
> Specification Drafts (CSD), Committee Specifications (CS), and OASIS
> standards. While it of course should the objective of a TC to get
> OASIS standard approvals for the specifications it develops, a TC may
> decide to advance a particular specification only to the CSD or CS level.
> - It takes a minimum of about two months to advance a CSD to a CS, and
> a minimum of about three months to advance a CS to an OASIS standard.
> - There is an obligation to submit all ODF OASIS standards to ISO. The
> ISO standardization process itself takes at least 6 months.
> - Each specification document requires editorial work (including
> clarifying last details and issues). A rough estimate could be that for
> two months specification work, 1 month editorial work is required.
> - Our TC process is member driven: Individual TC members may propose
> enhancements for ODF, but they are also responsible for advancing their
> proposals into a state where enough details are specified so that the
> proposals can be voted on and integrated into the specification by the
> TC editors. Which means that it is to a large degree under the control
> of the TC members themselves when an enhancement is ready to be
> considered for integration into the ODF specification.
> 
> Considering all this, it is realistic to assume that we cannot release
> OASIS standards more frequently than every two years, but even when we would only have a window of about 6 months where we can add enhancements into a specification document.
> 
> What I'm therefore suggesting is that we
> 
> a) make use of the CSD and CS levels of approval
> b) adopt a time-boxed or "train model" where we have previously agreed
> dates where we aim to have CSDs ready, and where we accept for a CSD
> only what is ready by when.
> c) decide for each CSD individually whether we want to get a higher level of approval or public reviews.
> 
> How could this look like in practice?
> 
> We may agree that we deliver CSDs every 6 months. This would mean that we would have a phase of 4 months open development where we integrate all proposals that are ready to be integrated, which means that they are detailed enough to be integrated and have been approved. After this 4 months, we would have a phase of two months where the proposals get integrated into the draft. We when vote on the draft, and most likely get a CSD that is published. After the CSD approval, we start working on the next CSD in the same way.
> 
> When a CSD has been approved, we also discuss and agree whether we want to start a 30-day public review for the draft, and ask for approval as a
> CS. But even if we do so, we would continue our work on the next CSD.
> 
> Where are a lot of things to consider for this decision: For instance
> how much new content we have in the specification. Or whether we have
> other public reviews running. Or where we are in the approval process of
> previous specifications. For this reason, it appears reasonable to not
> set up any rules for this in advance, but to just use the CSD approvals
> as checkpoints, and to decide individually for each CSD how to proceed.
> 
> When we decide to advance a CSD to a CS and got the CS approval, we
> would then discuss and decide whether want to advance it to an OASIS
> standard.
> 
> Where may of course be features that need more than four months to be
> developed. For these, we may set up sub committees, and may consider the
> deliverable of the sub committee as a proposal that we treat the same
> way as the other proposals.
> 
> 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
> - The "rush hour" we get when we are getting closer to the end of a
> feature definition phase is avoided, because if a proposal misses a specific CSD, the next opportunity is already 6 months later.
> - Assuming that we get comments in particular for new features, we get a
> better distribution of comments by having many "small" public reviews rather than a single "large" public review.
> 
> Feedback to these suggestions is of course very welcome. I also did present these ideas at the last OOoCon. The feedback I got there from users of the ODF specification was positive. The slides of the presentation are available here:
> 
> http://www.ooocon.org/index.php/ooocon/2010/paper/view/233
> 
> Best regards, and best wishes for the holiday season.
> 
> Michael
> 
> -- 
> 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
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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
> 

It is definitively not the intention of my proposal to avoid OS approval. Sorry if that hasn't been clear. What I'm suggesting is that we have frequent CSDs at fixed schedule. For each CSD we have the option to conduct public reviews, which are actually useful also for getting comments from SC34. The OASIS process would also allow us to advance a CSD to a CS, and if want to ask for an approval as an OASIS standard, we of course have to advance a CSD to a CS first. But I'm not recommending that we advance CSDs to a CS unless we want to ask for an OASIS standard approval. Michael On 17.12.2010 18:40, Mary McRae wrote: Just my $.02, but I would be careful of this approach since anyone who must follow the ISO path vs the OASIS one would not be able to implement new features/improvements/etc until a new OS submission to JTC1 occurred and was approved. The TC was greatly criticized for not sending v1.1; intentionally avoiding OS approval would, I think, be frowned upon by SC34. Best regards and best wishes to all for a very happy holiday season, Mary On Dec 17, 2010, at 8:03 AM, Michael Brauer wrote: Dear TC members, while we are waiting for the ODF 1.2 public review, I think it may be a good time to share a few thoughts how I could imagine that we adapt our specification process and schedule for future ODF versions to deliver specifications more frequently, and how to lower the time from a first feature proposal to a specification that contains the feature. I don't want to start with too many introductory words, but think a few observation may be reasonable, in particular for those who are new in the TC: - The OASIS TC process defines three levels of approval: Committee Specification Drafts (CSD), Committee Specifications (CS), and OASIS standards. While it of course should the objective of a TC to get OASIS standard approvals for the specifications it develops, a TC may decide to advance a particular specification only to the CSD or CS level. - It takes a minimum of about two months to advance a CSD to a CS, and a minimum of about three months to advance a CS to an OASIS standard. - There is an obligation to submit all ODF OASIS standards to ISO. The ISO standardization process itself takes at least 6 months. - Each specification document requires editorial work (including clarifying last details and issues). A rough estimate could be that for two months specification work, 1 month editorial work is required. - Our TC process is member driven: Individual TC members may propose enhancements for ODF, but they are also responsible for advancing their proposals into a state where enough details are specified so that the proposals can be voted on and integrated into the specification by the TC editors. Which means that it is to a large degree under the control of the TC members themselves when an enhancement is ready to be considered for integration into the ODF specification. Considering all this, it is realistic to assume that we cannot release OASIS standards more frequently than every two years, but even when we would only have a window of about 6 months where we can add enhancements into a specification document. What I'm therefore suggesting is that we a) make use of the CSD and CS levels of approval b) adopt a time-boxed or train model where we have previously agreed dates where we aim to have CSDs ready, and where we accept for a CSD only what is ready by when. c) decide for each CSD individually whether we want to get a higher level of approval or public reviews. How could this look like in practice? We may agree that we deliver CSDs every 6 months. This would mean that we would have a phase of 4 months open development where we integrate all proposals that are ready to be integrated, which means that they are detailed enough to be integrated and have been approved. After this 4 months, we would have a phase of two months where the proposals get integrated into the draft. We when vote on the draft, and most likely get a CSD that is published. After the CSD approval, we start working on the next CSD in the same way. When a CSD has been approved, we also discuss and agree whether we want to start a 30-day public review for the draft, and ask for approval as a CS. But even if we do so, we would continue our work on the next CSD. Where are a lot of things to consider for this decision: For instance how much new content we have in the specification. Or whether we have other public reviews running. Or where we are in the approval process of previous specifications. For this reason, it appears reasonable to not set up any rules for this in advance, but to just use the CSD approvals as checkpoints, and to decide individually for each CSD how to proceed. When we decide to advance a CSD to a CS and got the CS approval, we would then discuss and decide whether want to advance it to an OASIS standard. Where may of course be features that need more than four months to be developed. For these, we may set up sub committees, and may consider the deliverable of the sub committee as a proposal that we treat the same way as the other proposals. 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 - The rush hour we get when we are getting closer to the end of a feature definition phase is avoided, because if a proposal misses a specific CSD, the next opportunity is already 6 months later. - Assuming that we get comments in particular for new features, we get a better distribution of comments by having many small public reviews rather than a single large public review. Feedback to these suggestions is of course very welcome. I also did present these ideas at the last OOoCon. The feedback I got there from users of the ODF specification was positive. The slides of the presentation are available here: http://www.ooocon.org/index.php/ooocon/2010/paper/view/233 Best regards, and best wishes for the holiday season. Michael -- 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 --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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

Michael Brauer 

Hi Rob et al,

  Just one correction: #3 in your timeline is 30-day review rather than 60.

Mary 




On Dec 17, 2010, at 1:26 PM, robert_weir@us.ibm.com wrote:

> Michael Brauer 

Hi Rob, On 17.12.2010 19:26, robert_weir@us.ibm.com wrote: Note that I don't think the ISO portion of the train should determine our scheduling. IMHO, it is perfectly acceptable to start work on a new ODF version in OASIS while the previous version is still under review in ISO. In fact I think that will be the normal situation. I agree. Otherwise we would have to pause our work on a new specification for a year or so, what would also delay the next ISO version by a year. This is certainly in no ones interest. We might even want to propose a more detailed template for the release. For example, say for ODF 1.3 we say upfront that we will: 1) Produce monthly WDs until the specification is feature complete Yes, that's a good idea. 2) Set a target date for CSD 01. Assume CSD 01 goes for 30 day public review 3) Assume we get comments and revise once. Set a target date for CSD 02. If we adopt a train model, then the target dates for all CSDs are known in advance. If our trains leave every 6 months, then the target date for CSD 1 would be in 6 months from now, CSD 2 6 months later, and so on. 4) CSD 02 goes out for 15 ay public review 5) Move CSD 02 forward for CS. I think we should be careful advancing a CSD to CS if we don't want to advance it also to an OASIS standard. CSD 02 may be ready in a year from now. That may be to early for the next OASIS standard. But it may indeed be reasonable to agree in advance that at latest with CSD04, we will advance a CSD to an OASIS standard. I think every CSD should go out for public review, except maybe the first one. Note also that we have told SC34 that we will send them all CSD's for comment. Yes, that makes sense. I generally like the idea. I think this is the intent of WD, CSD and CS work products, to be milestones. Another, entirely different approach, would be to investigate what would be required to do a true multi-part standard, where the different parts could be advanced through the entire process independently. So in the train analogy, this would be parallel tracks. We considered this for ODF 1.2, but some (including me) thought that we needed some modularization work on the spec (and schema) before we could successfully and cleanly separate the parts. But if we were able to do this for ODF-Next, then that would allow additional flexibility. Of course, it would also cause additional complexity in JIRA, and generally on the project management side. I like the idea to have more parts (regardless whether we advance them to standards individually or not), but I fear that is nothing we can achieve in a very short term. And we have a lot of proposals outstanding that wait to be integrated in the ODF specification. What I would like to avoid is that we spend half a year or a year on further modularization before we are able to integrate proposals. But if there is enough interest in the TC for modularization, we may turn this into a longer running task, for instance by creating a SC. That SC may work out a proposal for modularization. And if that is ready, we may apply it to our standard track. Best regards Michael Regards, -Rob Michael -- 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 --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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

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.  

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.

There is an advantage to new features being worked out cooperatively among
implementers as mutually-agreed foreign extensions, extensions that are
handled appropriately in implementations that are unaware of them.  This
does not require ratification in the ODF 1.x namespace(s) and schema(s).
There is advantage to having them on their own "tracks."  With luck, the
results will be sufficiently well-specified and sufficiently desirable that
incorporation into ODF x.y is not difficult.  If the feature model is not
carried over wholesale, the form incorporated in the ODF x.y schemas and
namespaces will be differentiated and the implementations of the extension
can be adjusted in some way (and ideally there is harmonization or we aren't
talking about the same feature modeling at all).

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.




                                                

					
                                                    

        
                                                
				
                                                

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

[ ... ] 

"Dennis E. Hamilton" 

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

On Thu, 2011-01-13 at 06:57 -0700, Michael Brauer wrote: > Dennis E. Hamilton wrote: > > 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. > I concur with Dennis. Suggesting that implementers may use CSD's to justify the use of the ODF namespaces for feature will just continue the current nightmare of some implementations creating files claiming to be ODF1.2 before such a standard has been approved. If an implementor wants to use a feature proposed for a new standard it really should use a foreign namespace. If in the end that use will match the feature as adopted in an ODF standard it would be easy for any implementation supporting the feature in ODF also to support that foreign element. Andreas

"Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca> wrote on 01/13/2011 11:45:41 AM: > > I concur with Dennis. Suggesting that implementers may use CSD's to > justify the use of the ODF namespaces for feature will just continue the > current nightmare of some implementations creating files claiming to be > ODF1.2 before such a standard has been approved. If an implementor wants > to use a feature proposed for a new standard it really should use a > foreign namespace. If in the end that use will match the feature as > adopted in an ODF standard it would be easy for any implementation > supporting the feature in ODF also to support that foreign element. > I think the important thing is to have some consistency between what your office:version attribute is and what markup your document uses. If version = "1.0" or "1.1" then you shouldn't be using any ODF-namespaced enhancements from ODF. If you set version to "1.2", then I think you want to be conforming to some version of the ODF 1.2 draft. It would be odd not to. One can conform to a WD, or CSD or CS just as one can conform to a standard. Conformance is just the relation of the product to the conformance clause. It would be clearer, I think, if we had a consistent way to express a fine grained version, such as "1.2 (CSD06)" or even eventually "1.2 (Errata 01)". Remember, OASIS requires that we have conforming implementations before we can send a Committee Specification for ballot as an OASIS Standard. So there will always be a period of time when we have implementations of not-yet-approved specification. In any case, I'd rather have this problem (vendors implementing our drafts early) than the opposite problem (vendors being slow to implement our published standards). 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. Regards, -Rob

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. 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. Andreas -- Andreas J. Guelzow <andreas.guelzow@concordia.ab.ca> Concordia University College of Alberta

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 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. 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. Most of all, I think we owe it to the community of OpenDocument adopters to demonstrate care in this regard. - Dennis
Original Message----- From: Andreas J. Guelzow [ mailto:andreas.guelzow@concordia.ab.ca ] Sent: Thursday, January 13, 2011 16:42 To: office@lists.oasis-open.org Subject: Re: [office] Thoughts on ODF-Next 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. 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. Andreas -- Andreas J. Guelzow <andreas.guelzow@concordia.ab.ca> Concordia University College of Alberta --------------------------------------------------------------------- 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

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

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

"Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca> wrote on 01/13/2011 07:41:41 PM: > > Re: [office] Thoughts on ODF-Next > > 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. > This issue has been noted in the larger tech industry. For example, the 801.11 N wifi standard took 7 years to develop. But hardware supporting "draft" versions were in the market several years before the standard was finalized. This creates in incumbency effect that benefited large chip makers, who were able to simultaneously move on the market faster, but also ensure that the standard did not change contrary to their investment. So the effect is real. And we can certainly point to other vendors whose practice is to release a product first, and then submit the technology for standardization, but with committee charters that forbid incompatible changes. > 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. That is one approach, but not one that we (the ODF TC) have any ability to mandate. I suspect a standards organization that wanted to enforce something like this could do so via their control of the trademarks associated with the standard, e.g., they could have a policy that says you can only use the trademark for implementations that conform to published/approved versions of the standard, etc. But I'm not familiar with any organizations that have that rule. It is more common among proprietary specifications, e.g., if you want to say "Compatible with Windows 7" on your box, then you must follow the logo guidelines defined by Microsoft. Regards, -Rob

On Fri, 2011-01-14 at 08:50 -0700, robert_weir@us.ibm.com wrote: > "Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca> wrote on 01/13/2011 > 07:41:41 PM: > > > > Re: [office] Thoughts on ODF-Next > > > > 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. > > > > This issue has been noted in the larger tech industry. For example, the > 801.11 N wifi standard took 7 years to develop. But hardware supporting > "draft" versions were in the market several years before the standard was > finalized. This creates in incumbency effect that benefited large chip > makers, who were able to simultaneously move on the market faster, but > also ensure that the standard did not change contrary to their investment. > So the effect is real. And we can certainly point to other vendors whose > practice is to release a product first, and then submit the technology for > standardization, but with committee charters that forbid incompatible > changes. > > > 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. > > That is one approach, but not one that we (the ODF TC) have any ability to > mandate. > 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 at least should not encourage that behaviour as suggested. Andreas

Andreas said: > > > 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. > > That is one approach, but not one that we (the ODF TC) have any > > ability to mandate. > 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 think we > at least should not encourage that behaviour as suggested. Just my personal opinion - it is a sticky problem. If no one has attempted to implement the standard, then we have no real idea whether it is a complete or correct standard. But implementing a draft, especially in a non-beta product has perils, including having the standard change out from under you. We hit some of this in the signature work - the (proposed 1.2) standard reflects some practices that were incorporated into implementations built on the draft. Some of that was non-optimal, and resulted in compromises in the standard. Some of it helped inform the standard and was beneficial. Overall, I was glad there was an implementation to draw from - made the result less ambiguous, even if there were also some drawbacks. At the end of the day, I don't think there is one right answer - there's pros and cons to each approach.

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

Michael, On Mon, 2011-01-17 at 11:59 +0100, Michael Brauer wrote: > 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? > I don't think successive CSDs would all be called ODF 1.3, without more. See the Naming guidelines, http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html , in part: > The process of document revision as a technical activity takes place > when an approved Work Product is edited and is assigned a new Working > Draft revision number. Textually, a revision is a two-digit number > associated with a Working Draft or a specific stage corresponding to a > published instance. A revision number begins with "01" and is > incremented by 1 for each release at each maturity level (stage). Note that "Work Product" means anything voted upon by the committee. Hope you are at the start of a great day! Patrick -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau Newcomb Number: 1

On Mon, 2011-01-17 at 18:24 -0700, Patrick Durusau wrote: > Michael, > > On Mon, 2011-01-17 at 11:59 +0100, Michael Brauer wrote: > > 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? > > > > I don't think successive CSDs would all be called ODF 1.3, without more. > > See the Naming guidelines, > http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html , in > part: Patrick, we are not talking about what the TC or OASIS calls the various CSD but what the version string would be that is used in ODF files created by vendors that implement ODF1.3CSD1. I don't think the version string should be just "1.3" > > > > The process of document revision as a technical activity takes place > > when an approved Work Product is edited and is assigned a new Working > > Draft revision number. Textually, a revision is a two-digit number > > associated with a Working Draft or a specific stage corresponding to a > > published instance. A revision number begins with "01" and is > > incremented by 1 for each release at each maturity level (stage). > > Note that "Work Product" means anything voted upon by the committee. > Andreas

Andreas, Andreas J. Guelzow wrote: > On Mon, 2011-01-17 at 18:24 -0700, Patrick Durusau wrote: >> Michael, >> >> On Mon, 2011-01-17 at 11:59 +0100, Michael Brauer wrote: >>> 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? >>> >> I don't think successive CSDs would all be called ODF 1.3, without more. >> >> See the Naming guidelines, >> http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html , in >> part: > > Patrick, we are not talking about what the TC or OASIS calls the various > CSD but what the version string would be that is used in ODF files > created by vendors that implement ODF1.3CSD1. I don't think the version > string should be just "1.3" What we are developing are OASIS standards, and the CSDs are just intermediate draft on our way to the OASIS standards. I'm not in favor of using different versions strings, since this may be misinterpreted as giving CSD more weight than they have. But there are other options. We may for instance add an attribute that maybe used in content.xml, styles.xml, etc. and which links to the schema against wich the file is valid. All schemas we approve will be available at docs.oasis-open.org, and the name of the schema contains the CSD number. It therefore unambiguously identifies the CSD that has been used for the implementation that created a document. The same method could be used to link extended ODF documents to a schema that includes the used extensions. This would allow to validate such documents, what is not possible right now. Best regards Michael -- 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

On Tue, 2011-01-18 at 01:04 -0700, Michael Brauer wrote: > Andreas J. Guelzow wrote: > > On Mon, 2011-01-17 at 18:24 -0700, Patrick Durusau wrote: > >> On Mon, 2011-01-17 at 11:59 +0100, Michael Brauer wrote: > >>> 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? > >>> > >> I don't think successive CSDs would all be called ODF 1.3, without more. > >> > >> See the Naming guidelines, > >> http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html , in > >> part: > > > > Patrick, we are not talking about what the TC or OASIS calls the various > > CSD but what the version string would be that is used in ODF files > > created by vendors that implement ODF1.3CSD1. I don't think the version > > string should be just "1.3" > > What we are developing are OASIS standards, and the CSDs are just > intermediate draft on our way to the OASIS standards. I'm not in favor > of using different versions strings, since this may be misinterpreted as > giving CSD more weight than they have. If we do not distinguish CSDs from approved standards the version string is useless. It was my understanding that the version string can be used to determine the meaning of the various elements by providing an unambigious indicator of the document describing the elements. > > But there are other options. We may for instance add an attribute that > maybe used in content.xml, styles.xml, etc. and which links to the > schema against wich the file is valid. All schemas we approve will be > available at docs.oasis-open.org, and the name of the schema contains > the CSD number. It therefore unambiguously identifies the CSD that has > been used for the implementation that created a document. > > The same method could be used to link extended ODF documents to a schema > that includes the used extensions. This would allow to validate such > documents, what is not possible right now. This will make the situation even worse: having an attribute whoese value can be essentially an arbitrary schema URL does not allow us to use that string to recognize the meaning of the attributes since we are likely to encounter URLs we don't know. Unless there is some guaranteed way for us to recognize that a given ODF file can be interpreted as described in a certain ODF description, support for ODF becomes virtually impossible. Andreas >

Andreas, On 18.01.2011 09:17, Andreas J. Guelzow wrote: 1295338639.2499.7.camel@kirkman type= cite > If we do not distinguish CSDs from approved standards the version string is useless. It was my understanding that the version string can be used to determine the meaning of the various elements by providing an unambigious indicator of the document describing the elements. What we are developing will be an ODF 1.3 OASIS standard, or maybe a 2.0. All committee drafts will be intermediate drafts, and I don't feel comfortable if these get distinct version numbers in the schema. Further, A CSD may be send out for public review. It is then called a committee specification public review draft. We have seen this for ODF 1.2 CSD06, where the same specification also got ODF1.2 CSPRD02. But we cannot change the schema between a CSD and a CSPRD. We also cannot change the schema when we approve a CSPRD as CS, or when it gets approved as OS. So, encoding the state of a specification into an attribute value in the schema does not work. Beside that, we must not overestimate the issue of incompatible changes between CSDs. We are developing ODF for may years now, and the version attribute always was corresponding to the OASIS standard we are developing. I'm not aware of any severe issues this caused. If you are aware of any examples where this caused an issue, please let us know them, so that we have something real where we can check how we could have avoided the issue. Further, before a proposal gets into the specification, we, the TC, are discussing and reviewing it. Only if we think that the proposal is good and stable, we are accepting it. In the past, the vast majority of proposals was accepted once, and did never change since when. Changes to accepted proposals are the exception. I don't know why this should suddenly change. 1295338639.2499.7.camel@kirkman type= cite > But there are other options. We may for instance add an attribute that maybe used in content.xml, styles.xml, etc. and which links to the schema against wich the file is valid. All schemas we approve will be available at docs.oasis-open.org, and the name of the schema contains the CSD number. It therefore unambiguously identifies the CSD that has been used for the implementation that created a document. The same method could be used to link extended ODF documents to a schema that includes the used extensions. This would allow to validate such documents, what is not possible right now. This will make the situation even worse: having an attribute whoese value can be essentially an arbitrary schema URL does not allow us to use that string to recognize the meaning of the attributes since we are likely to encounter URLs we don't know. You have to consider here that it us who defines ODF. We can set up whatever requirements or recommendation for the URL what we need is required or useful. If we state that conforming documents should or shall reference the schema on docs.oasis-open.org that was used by the implementation, then implementations have to reference exactly these schemas. Further, I think all implementors are interested in creating documents that are interoperable. Why should anyone use random URL values? 1295338639.2499.7.camel@kirkman type= cite > Unless there is some guaranteed way for us to recognize that a given ODF file can be interpreted as described in a certain ODF description, support for ODF becomes virtually impossible. I don't agree, but I've made a suggestion how the problem anyway could be solved. It's not in the version string for the reasons I've outlined below, but it anyway is a possible solution. If you have an alternative proposal that is in line with the OASIS process and the spirit of the OASIS standardization process, I'm all ears. Michael 1295338639.2499.7.camel@kirkman 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

On Tue, 2011-01-18 at 06:27 -0700, Michael Brauer wrote: > On 18.01.2011 09:17, Andreas J. Guelzow wrote: > > If we do not distinguish CSDs from approved standards the version string > > is useless. It was my understanding that the version string can be used > > to determine the meaning of the various elements by providing an > > unambigious indicator of the document describing the elements. > > > What we are developing will be an ODF 1.3 OASIS standard, or maybe a > 2.0. All committee drafts will be intermediate drafts, and > I don't feel comfortable if these get distinct version numbers in the > schema. Further, A CSD may be send out for public review. It is then > called a > committee specification public review draft. We have seen this for ODF > 1.2 CSD06, where the same specification also got ODF1.2 CSPRD02. But > we cannot change the schema between a CSD and a CSPRD. We also cannot > change the schema when we approve a CSPRD as CS, or when it gets > approved as OS. So, encoding the state of a specification into an > attribute value in the schema does not work. I fail to see why it wouldn't work? If two document are otherwise identical there is no reason they could not retain the same version string. > > Beside that, we must not overestimate the issue of incompatible > changes between CSDs. We are developing ODF for may years now, > and the version attribute always was corresponding to the OASIS > standard we are developing. I'm not aware of any severe issues > this caused. If you are aware of any examples where this caused an > issue, please let us know them, so that we have something real > where we can check how we could have avoided the issue. We must not underestimate them either. The work for 1.2 has shown the effect OpenOffice.org's decision to ship something called "1.2" had on (a) the work on ODF1.2 (by essentially restricting the possibility of providing a better description for some features since "this is not what we do in OOo") and (b) created significant problem for us as Gnumeric developers when we had to handle inconsistencies between the "current" draft and what OOo wrote into its files. (In addition since users unfortunately perceive (if incorrectly) OOo as a sort of reference implementation for ODF we even had to deal with the fact that when OOo wrote something into a file it was considered a Gnumeric bug when the interpretation varied.) Note that I am not talking about difference in schema but in semantics, ie. what exactly certain elements and attributes mean. For example OO writes 1.2 chart:interpolation="b-spline" with a meaning that differs greatly from its precise definition in the latest drafts. The latest drafts make it clear that the spline passes through the data points while earlier drafts used the data points as control points only. This is greatly visible. > > Further, before a proposal gets into the specification, we, the TC, > are discussing and reviewing it. Only if we think that the proposal is > good and stable, > we are accepting it. In the past, the vast majority of proposals was > accepted once, and did never change since when. Changes to accepted > proposals are the exception. I don't know why this should suddenly > change. > > > But there are other options. We may for instance add an attribute that > > > maybe used in content.xml, styles.xml, etc. and which links to the > > > schema against wich the file is valid. All schemas we approve will be > > > available at docs.oasis-open.org, and the name of the schema contains > > > the CSD number. It therefore unambiguously identifies the CSD that has > > > been used for the implementation that created a document. > > > > > > The same method could be used to link extended ODF documents to a schema > > > that includes the used extensions. This would allow to validate such > > > documents, what is not possible right now. > > > > > > > This will make the situation even worse: having an attribute whoese > > value can be essentially an arbitrary schema URL does not allow us to > > use that string to recognize the meaning of the attributes since we are > > likely to encounter URLs we don't know. > > > You have to consider here that it us who defines ODF. We can set up > whatever requirements or > recommendation for the URL what we need is required or useful. If we > state that conforming documents should or shall reference the schema > on docs.oasis-open.org that was used by the implementation, then > implementations have to reference exactly these schemas. The schemas on docs.oasis-open.org would not include any schemas "that include the used extensions" so I don't understand how this would work for your previous suggestion. > > Further, I think all implementors are interested in creating documents > that are interoperable. Why should anyone use random URL values? I meant "random URL values" as URL values that can only be discovered by checking those implementations not by knowledge of the standard and any committee drafts. > > > Unless there is some guaranteed way for us to recognize that a given ODF > > file can be interpreted as described in a certain ODF description, > > support for ODF becomes virtually impossible. > > > I don't agree, but I've made a suggestion how the problem anyway could > be solved. It's not in the version string for the reasons I've > outlined below, There is nothing given below and I disagree with (or at a minimum do not follow) your reasoning above. Andreas > but it anyway is a possible solution. If you have an alternative > proposal that is in line with the OASIS process and the spirit of the > OASIS standardization process, I'm all ears. >

Hello, Michael Brauer wrote: > What we are developing are OASIS standards, and the CSDs are just > intermediate draft on our way to the OASIS standards. I'm not in favor > of using different versions strings, since this may be misinterpreted as > giving CSD more weight than they have. > > But there are other options. We may for instance add an attribute that > maybe used in content.xml, styles.xml, etc. and which links to the > schema against wich the file is valid. All schemas we approve will be > available at docs.oasis-open.org, and the name of the schema contains > the CSD number. It therefore unambiguously identifies the CSD that has > been used for the implementation that created a document. > > The same method could be used to link extended ODF documents to a schema > that includes the used extensions. This would allow to validate such > documents, what is not possible right now. 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? Thorsten

<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. 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. In other words: 1) We have no control over what vendors implement and when they implement it and what they call it. 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. -Rob

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

Andreas, On Mon, 2011-01-17 at 20:35 -0700, Andreas J. Guelzow wrote: > On Mon, 2011-01-17 at 18:24 -0700, Patrick Durusau wrote: > > Michael, > > > > On Mon, 2011-01-17 at 11:59 +0100, Michael Brauer wrote: > > > 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? > > > > > > > I don't think successive CSDs would all be called ODF 1.3, without more. > > > > See the Naming guidelines, > > http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html , in > > part: > > Patrick, we are not talking about what the TC or OASIS calls the various > CSD but what the version string would be that is used in ODF files > created by vendors that implement ODF1.3CSD1. I don't think the version > string should be just "1.3" OK, but shouldn't what the TC and OASIS "calls" the next version also be what appears in the version string? I agree the version string should not be just "1.3." Hope you are at the start of a great day! Patrick > > > > > > > The process of document revision as a technical activity takes place > > > when an approved Work Product is edited and is assigned a new Working > > > Draft revision number. Textually, a revision is a two-digit number > > > associated with a Working Draft or a specific stage corresponding to a > > > published instance. A revision number begins with "01" and is > > > incremented by 1 for each release at each maturity level (stage). > > > > Note that "Work Product" means anything voted upon by the committee. > > > > Andreas > >

Dear TC members, thank you very much for the feedback to these suggestions. That is very helpful. I will answer to a few concerns on the mailing list, but would like to discuss this topic in one of our next TC calls. We are will start to work on ODF-Next very soon, and I think we need top agree on a schedule for our future work very soon. Best regards Michael On 17.12.2010 14:03, Michael Brauer wrote: Dear TC members, while we are waiting for the ODF 1.2 public review, I think it may be a good time to share a few thoughts how I could imagine that we adapt our specification process and schedule for future ODF versions to deliver specifications more frequently, and how to lower the time from a first feature proposal to a specification that contains the feature. I don't want to start with too many introductory words, but think a few observation may be reasonable, in particular for those who are new in the TC: - The OASIS TC process defines three levels of approval: Committee Specification Drafts (CSD), Committee Specifications (CS), and OASIS standards. While it of course should the objective of a TC to get OASIS standard approvals for the specifications it develops, a TC may decide to advance a particular specification only to the CSD or CS level. - It takes a minimum of about two months to advance a CSD to a CS, and a minimum of about three months to advance a CS to an OASIS standard. - There is an obligation to submit all ODF OASIS standards to ISO. The ISO standardization process itself takes at least 6 months. - Each specification document requires editorial work (including clarifying last details and issues). A rough estimate could be that for two months specification work, 1 month editorial work is required. - Our TC process is member driven: Individual TC members may propose enhancements for ODF, but they are also responsible for advancing their proposals into a state where enough details are specified so that the proposals can be voted on and integrated into the specification by the TC editors. Which means that it is to a large degree under the control of the TC members themselves when an enhancement is ready to be considered for integration into the ODF specification. Considering all this, it is realistic to assume that we cannot release OASIS standards more frequently than every two years, but even when we would only have a window of about 6 months where we can add enhancements into a specification document. What I'm therefore suggesting is that we a) make use of the CSD and CS levels of approval b) adopt a time-boxed or train model where we have previously agreed dates where we aim to have CSDs ready, and where we accept for a CSD only what is ready by when. c) decide for each CSD individually whether we want to get a higher level of approval or public reviews. How could this look like in practice? We may agree that we deliver CSDs every 6 months. This would mean that we would have a phase of 4 months open development where we integrate all proposals that are ready to be integrated, which means that they are detailed enough to be integrated and have been approved. After this 4 months, we would have a phase of two months where the proposals get integrated into the draft. We when vote on the draft, and most likely get a CSD that is published. After the CSD approval, we start working on the next CSD in the same way. When a CSD has been approved, we also discuss and agree whether we want to start a 30-day public review for the draft, and ask for approval as a CS. But even if we do so, we would continue our work on the next CSD. Where are a lot of things to consider for this decision: For instance how much new content we have in the specification. Or whether we have other public reviews running. Or where we are in the approval process of previous specifications. For this reason, it appears reasonable to not set up any rules for this in advance, but to just use the CSD approvals as checkpoints, and to decide individually for each CSD how to proceed. When we decide to advance a CSD to a CS and got the CS approval, we would then discuss and decide whether want to advance it to an OASIS standard. Where may of course be features that need more than four months to be developed. For these, we may set up sub committees, and may consider the deliverable of the sub committee as a proposal that we treat the same way as the other proposals. 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 - The rush hour we get when we are getting closer to the end of a feature definition phase is avoided, because if a proposal misses a specific CSD, the next opportunity is already 6 months later. - Assuming that we get comments in particular for new features, we get a better distribution of comments by having many small public reviews rather than a single large public review. Feedback to these suggestions is of course very welcome. I also did present these ideas at the last OOoCon. The feedback I got there from users of the ODF specification was positive. The slides of the presentation are available here: http://www.ooocon.org/index.php/ooocon/2010/paper/view/233 Best regards, and best wishes for the holiday season. 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

Hi, thanks for all the contributions to the discussion since yesterday. It seems that all concerns that have been raised are regarding the question whether or not we should encourage vendors to implement CSDs. That's a very interesting discussion, but only one aspect of my suggestions. I'm therefore interested to learn if there are other concerns, or if you otherwise agree to the suggestions. Best regards Michael On 13.01.2011 11:39, Michael Brauer wrote: 4D2ED653.7060905@oracle.com type= cite > Dear TC members, thank you very much for the feedback to these suggestions. That is very helpful. I will answer to a few concerns on the mailing list, but would like to discuss this topic in one of our next TC calls. We are will start to work on ODF-Next very soon, and I think we need top agree on a schedule for our future work very soon. Best regards Michael On 17.12.2010 14:03, Michael Brauer wrote: Dear TC members, while we are waiting for the ODF 1.2 public review, I think it may be a good time to share a few thoughts how I could imagine that we adapt our specification process and schedule for future ODF versions to deliver specifications more frequently, and how to lower the time from a first feature proposal to a specification that contains the feature. I don't want to start with too many introductory words, but think a few observation may be reasonable, in particular for those who are new in the TC: - The OASIS TC process defines three levels of approval: Committee Specification Drafts (CSD), Committee Specifications (CS), and OASIS standards. While it of course should the objective of a TC to get OASIS standard approvals for the specifications it develops, a TC may decide to advance a particular specification only to the CSD or CS level. - It takes a minimum of about two months to advance a CSD to a CS, and a minimum of about three months to advance a CS to an OASIS standard. - There is an obligation to submit all ODF OASIS standards to ISO. The ISO standardization process itself takes at least 6 months. - Each specification document requires editorial work (including clarifying last details and issues). A rough estimate could be that for two months specification work, 1 month editorial work is required. - Our TC process is member driven: Individual TC members may propose enhancements for ODF, but they are also responsible for advancing their proposals into a state where enough details are specified so that the proposals can be voted on and integrated into the specification by the TC editors. Which means that it is to a large degree under the control of the TC members themselves when an enhancement is ready to be considered for integration into the ODF specification. Considering all this, it is realistic to assume that we cannot release OASIS standards more frequently than every two years, but even when we would only have a window of about 6 months where we can add enhancements into a specification document. What I'm therefore suggesting is that we a) make use of the CSD and CS levels of approval b) adopt a time-boxed or train model where we have previously agreed dates where we aim to have CSDs ready, and where we accept for a CSD only what is ready by when. c) decide for each CSD individually whether we want to get a higher level of approval or public reviews. How could this look like in practice? We may agree that we deliver CSDs every 6 months. This would mean that we would have a phase of 4 months open development where we integrate all proposals that are ready to be integrated, which means that they are detailed enough to be integrated and have been approved. After this 4 months, we would have a phase of two months where the proposals get integrated into the draft. We when vote on the draft, and most likely get a CSD that is published. After the CSD approval, we start working on the next CSD in the same way. When a CSD has been approved, we also discuss and agree whether we want to start a 30-day public review for the draft, and ask for approval as a CS. But even if we do so, we would continue our work on the next CSD. Where are a lot of things to consider for this decision: For instance how much new content we have in the specification. Or whether we have other public reviews running. Or where we are in the approval process of previous specifications. For this reason, it appears reasonable to not set up any rules for this in advance, but to just use the CSD approvals as checkpoints, and to decide individually for each CSD how to proceed. When we decide to advance a CSD to a CS and got the CS approval, we would then discuss and decide whether want to advance it to an OASIS standard. Where may of course be features that need more than four months to be developed. For these, we may set up sub committees, and may consider the deliverable of the sub committee as a proposal that we treat the same way as the other proposals. 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 - The rush hour we get when we are getting closer to the end of a feature definition phase is avoided, because if a proposal misses a specific CSD, the next opportunity is already 6 months later. - Assuming that we get comments in particular for new features, we get a better distribution of comments by having many small public reviews rather than a single large public review. Feedback to these suggestions is of course very welcome. I also did present these ideas at the last OOoCon. The feedback I got there from users of the ODF specification was positive. The slides of the presentation are available here: http://www.ooocon.org/index.php/ooocon/2010/paper/view/233 Best regards, and best wishes for the holiday season. 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 -- 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

Michael, A question on your scheduling: > > > Considering all this, it is realistic to assume that we cannot > > > release > > > OASIS standards more frequently than every two years, but even > > > when we would only have a window of about 6 months where we can > > > add enhancements into a specification document. OK, but what would be the content of that OASIS standard? I am assuming, perhaps incorrectly, it would be at the three prior CSD bundled up for that OASIS standard. Yes? Assume Jan. 1, 2011 the train starts up: 1st CSD - 6 months 2nd CSD - 12 months 3rd CSD - 18 months so isn't the sum of all three going into CS - 24 months? I think you imply as much but just wanted to be sure. Hope you are having a great day! Patrick PS: I do recognize that current OASIS mechanisms make collaboration with other standards organizations difficult but that isn't an issue we can resolve in this forum. On Fri, 2011-01-14 at 10:10 +0100, Michael Brauer wrote: > Hi, > > thanks for all the contributions to the discussion since yesterday. It > seems that all concerns that have been raised are regarding the > question whether or not we should encourage vendors to implement CSDs. > That's a very interesting discussion, but only one aspect of my > suggestions. I'm therefore interested to learn if there are other > concerns, or if you otherwise agree to the suggestions. > > Best regards > > Michael > > On 13.01.2011 11:39, Michael Brauer wrote: > > Dear TC members, > > > > thank you very much for the feedback to these suggestions. That is > > very helpful. I will answer to a few concerns on the mailing list, > > but would like to discuss this topic in one of our next TC calls. We > > are will start to work on ODF-Next very soon, and I think we need > > top agree on a schedule for our future work very soon. > > > > Best regards > > > > Michael > > > > > > > > On 17.12.2010 14:03, Michael Brauer wrote: > > > Dear TC members, > > > > > > while we are waiting for the ODF 1.2 public review, I think it may > > > be a > > > good time to share a few thoughts how I could imagine that we > > > adapt our > > > specification process and schedule for future ODF versions to > > > deliver > > > specifications more frequently, and how to lower the time from a > > > first > > > feature proposal to a specification that contains the feature. > > > > > > I don't want to start with too many introductory words, but think > > > a few > > > observation may be reasonable, in particular for those who are new > > > in > > > the TC: > > > > > > - The OASIS TC process defines three levels of approval: > > > Committee > > > Specification Drafts (CSD), Committee Specifications (CS), and > > > OASIS > > > standards. While it of course should the objective of a TC to get > > > OASIS standard approvals for the specifications it develops, a TC > > > may > > > decide to advance a particular specification only to the CSD or CS > > > level. > > > - It takes a minimum of about two months to advance a CSD to a CS, > > > and > > > a minimum of about three months to advance a CS to an OASIS > > > standard. > > > - There is an obligation to submit all ODF OASIS standards to ISO. > > > The > > > ISO standardization process itself takes at least 6 months. > > > - Each specification document requires editorial work (including > > > clarifying last details and issues). A rough estimate could be > > > that for > > > two months specification work, 1 month editorial work is > > > required. > > > - Our TC process is member driven: Individual TC members may > > > propose > > > enhancements for ODF, but they are also responsible for advancing > > > their > > > proposals into a state where enough details are specified so that > > > the > > > proposals can be voted on and integrated into the specification by > > > the > > > TC editors. Which means that it is to a large degree under the > > > control > > > of the TC members themselves when an enhancement is ready to be > > > considered for integration into the ODF specification. > > > > > > Considering all this, it is realistic to assume that we cannot > > > release > > > OASIS standards more frequently than every two years, but even > > > when we would only have a window of about 6 months where we can > > > add enhancements into a specification document. > > > > > > What I'm therefore suggesting is that we > > > > > > a) make use of the CSD and CS levels of approval > > > b) adopt a time-boxed or "train model" where we have previously > > > agreed > > > dates where we aim to have CSDs ready, and where we accept for a > > > CSD > > > only what is ready by when. > > > c) decide for each CSD individually whether we want to get a > > > higher level of approval or public reviews. > > > > > > How could this look like in practice? > > > > > > We may agree that we deliver CSDs every 6 months. This would mean > > > that we would have a phase of 4 months open development where we > > > integrate all proposals that are ready to be integrated, which > > > means that they are detailed enough to be integrated and have been > > > approved. After this 4 months, we would have a phase of two months > > > where the proposals get integrated into the draft. We when vote on > > > the draft, and most likely get a CSD that is published. After the > > > CSD approval, we start working on the next CSD in the same way. > > > > > > When a CSD has been approved, we also discuss and agree whether we > > > want to start a 30-day public review for the draft, and ask for > > > approval as a > > > CS. But even if we do so, we would continue our work on the next > > > CSD. > > > > > > Where are a lot of things to consider for this decision: For > > > instance > > > how much new content we have in the specification. Or whether we > > > have > > > other public reviews running. Or where we are in the approval > > > process of > > > previous specifications. For this reason, it appears reasonable to > > > not > > > set up any rules for this in advance, but to just use the CSD > > > approvals > > > as checkpoints, and to decide individually for each CSD how to > > > proceed. > > > > > > When we decide to advance a CSD to a CS and got the CS approval, > > > we > > > would then discuss and decide whether want to advance it to an > > > OASIS > > > standard. > > > > > > Where may of course be features that need more than four months to > > > be > > > developed. For these, we may set up sub committees, and may > > > consider the > > > deliverable of the sub committee as a proposal that we treat the > > > same > > > way as the other proposals. > > > > > > 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 > > > - The "rush hour" we get when we are getting closer to the end of > > > a > > > feature definition phase is avoided, because if a proposal misses > > > a specific CSD, the next opportunity is already 6 months later. > > > - Assuming that we get comments in particular for new features, we > > > get a > > > better distribution of comments by having many "small" public > > > reviews rather than a single "large" public review. > > > > > > Feedback to these suggestions is of course very welcome. I also > > > did present these ideas at the last OOoCon. The feedback I got > > > there from users of the ODF specification was positive. The slides > > > of the presentation are available here: > > > > > > http://www.ooocon.org/index.php/ooocon/2010/paper/view/233 > > > > > > Best regards, and best wishes for the holiday season. > > > > > > Michael > > > > > > > -- > > Oracle > > 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 > > > > Green Oracle Oracle is committed to developing practices and > > products that help protect the environment > > -- > Oracle > 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 > > Green Oracle Oracle is committed to developing practices and products > that help protect the environment

Patrick, On 14.01.2011 11:23, Patrick Durusau wrote: 1295000614.26257.3209.camel@ratatosk.home.org type= cite > Michael, A question on your scheduling: Considering all this, it is realistic to assume that we cannot release OASIS standards more frequently than every two years, but even when we would only have a window of about 6 months where we can add enhancements into a specification document. OK, but what would be the content of that OASIS standard? I am assuming, perhaps incorrectly, it would be at the three prior CSD bundled up for that OASIS standard. Yes? Yes. My assumption is that that the 2nd CSD contains all of the 1st CSD, the 3rd all of the 2nd, and so on. So, actually everything would be as before, except that we agree to have prepare high-quality intermediate CSD's every 6 months. Best regards Michael 1295000614.26257.3209.camel@ratatosk.home.org type= cite > Assume Jan. 1, 2011 the train starts up: 1st CSD - 6 months 2nd CSD - 12 months 3rd CSD - 18 months so isn't the sum of all three going into CS - 24 months? I think you imply as much but just wanted to be sure. Hope you are having a great day! Patrick PS: I do recognize that current OASIS mechanisms make collaboration with other standards organizations difficult but that isn't an issue we can resolve in this forum. On Fri, 2011-01-14 at 10:10 +0100, Michael Brauer wrote: Hi, thanks for all the contributions to the discussion since yesterday. It seems that all concerns that have been raised are regarding the question whether or not we should encourage vendors to implement CSDs. That's a very interesting discussion, but only one aspect of my suggestions. I'm therefore interested to learn if there are other concerns, or if you otherwise agree to the suggestions. Best regards Michael On 13.01.2011 11:39, Michael Brauer wrote: Dear TC members, thank you very much for the feedback to these suggestions. That is very helpful. I will answer to a few concerns on the mailing list, but would like to discuss this topic in one of our next TC calls. We are will start to work on ODF-Next very soon, and I think we need top agree on a schedule for our future work very soon. Best regards Michael On 17.12.2010 14:03, Michael Brauer wrote: Dear TC members, while we are waiting for the ODF 1.2 public review, I think it may be a good time to share a few thoughts how I could imagine that we adapt our specification process and schedule for future ODF versions to deliver specifications more frequently, and how to lower the time from a first feature proposal to a specification that contains the feature. I don't want to start with too many introductory words, but think a few observation may be reasonable, in particular for those who are new in the TC: - The OASIS TC process defines three levels of approval: Committee Specification Drafts (CSD), Committee Specifications (CS), and OASIS standards. While it of course should the objective of a TC to get OASIS standard approvals for the specifications it develops, a TC may decide to advance a particular specification only to the CSD or CS level. - It takes a minimum of about two months to advance a CSD to a CS, and a minimum of about three months to advance a CS to an OASIS standard. - There is an obligation to submit all ODF OASIS standards to ISO. The ISO standardization process itself takes at least 6 months. - Each specification document requires editorial work (including clarifying last details and issues). A rough estimate could be that for two months specification work, 1 month editorial work is required. - Our TC process is member driven: Individual TC members may propose enhancements for ODF, but they are also responsible for advancing their proposals into a state where enough details are specified so that the proposals can be voted on and integrated into the specification by the TC editors. Which means that it is to a large degree under the control of the TC members themselves when an enhancement is ready to be considered for integration into the ODF specification. Considering all this, it is realistic to assume that we cannot release OASIS standards more frequently than every two years, but even when we would only have a window of about 6 months where we can add enhancements into a specification document. What I'm therefore suggesting is that we a) make use of the CSD and CS levels of approval b) adopt a time-boxed or train model where we have previously agreed dates where we aim to have CSDs ready, and where we accept for a CSD only what is ready by when. c) decide for each CSD individually whether we want to get a higher level of approval or public reviews. How could this look like in practice? We may agree that we deliver CSDs every 6 months. This would mean that we would have a phase of 4 months open development where we integrate all proposals that are ready to be integrated, which means that they are detailed enough to be integrated and have been approved. After this 4 months, we would have a phase of two months where the proposals get integrated into the draft. We when vote on the draft, and most likely get a CSD that is published. After the CSD approval, we start working on the next CSD in the same way. When a CSD has been approved, we also discuss and agree whether we want to start a 30-day public review for the draft, and ask for approval as a CS. But even if we do so, we would continue our work on the next CSD. Where are a lot of things to consider for this decision: For instance how much new content we have in the specification. Or whether we have other public reviews running. Or where we are in the approval process of previous specifications. For this reason, it appears reasonable to not set up any rules for this in advance, but to just use the CSD approvals as checkpoints, and to decide individually for each CSD how to proceed. When we decide to advance a CSD to a CS and got the CS approval, we would then discuss and decide whether want to advance it to an OASIS standard. Where may of course be features that need more than four months to be developed. For these, we may set up sub committees, and may consider the deliverable of the sub committee as a proposal that we treat the same way as the other proposals. 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 - The rush hour we get when we are getting closer to the end of a feature definition phase is avoided, because if a proposal misses a specific CSD, the next opportunity is already 6 months later. - Assuming that we get comments in particular for new features, we get a better distribution of comments by having many small public reviews rather than a single large public review. Feedback to these suggestions is of course very welcome. I also did present these ideas at the last OOoCon. The feedback I got there from users of the ODF specification was positive. The slides of the presentation are available here: http://www.ooocon.org/index.php/ooocon/2010/paper/view/233 Best regards, and best wishes for the holiday season. Michael -- Oracle 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 Green Oracle Oracle is committed to developing practices and products that help protect the environment -- Oracle 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 Green Oracle Oracle is committed to developing practices and products that help protect the environment -- 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

Michael, I just saw your response on the CSDs to appear in an OASIS standard response and the requirement that we prepare: > high-quality intermediate CSD's every 6 months. > I think the following, which I was already writing, might help in that regard. Since the TC meets only once a week there isn't a lot of time for discussion of the details of proposals. I don't know that anyone would take advantage of it, but perhaps the TC should consider a second call every week, perhaps at varying times to accommodate members in different locations, for discussion/improvement of proposals. A call to last up to 2 hours. Anyone who has a proposal or who wants to make a proposal simply posts a request to be on the agenda for such a call. The only requirement being that a proposal be available for attendees to review prior to the call. This would not take the place of sub-committees where more substantial revisions are formulated but would be a way to get materials into the best shape possible for later evaluation by the TC. Just thinking that if we are serious about adopting a train approach, then we need to also be serious about devoting the resources to make that approach work for everyone. Including people who may need help in refining their proposals. Such meetings would not count for voting requirements in the TC. To avoid over-burdening you and Rob, I would be happy to chair such meetings. Or either one of you could, since I am concerned with using this to advance editorial work on proposals. Hope you are looking forward to a great weekend! Patrick On Fri, 2011-01-14 at 10:10 +0100, Michael Brauer wrote: > Hi, > > thanks for all the contributions to the discussion since yesterday. It > seems that all concerns that have been raised are regarding the > question whether or not we should encourage vendors to implement CSDs. > That's a very interesting discussion, but only one aspect of my > suggestions. I'm therefore interested to learn if there are other > concerns, or if you otherwise agree to the suggestions. > > Best regards > > Michael > > On 13.01.2011 11:39, Michael Brauer wrote: > > Dear TC members, > > > > thank you very much for the feedback to these suggestions. That is > > very helpful. I will answer to a few concerns on the mailing list, > > but would like to discuss this topic in one of our next TC calls. We > > are will start to work on ODF-Next very soon, and I think we need > > top agree on a schedule for our future work very soon. > > > > Best regards > > > > Michael > > > > > > > > On 17.12.2010 14:03, Michael Brauer wrote: > > > Dear TC members, > > > > > > while we are waiting for the ODF 1.2 public review, I think it may > > > be a > > > good time to share a few thoughts how I could imagine that we > > > adapt our > > > specification process and schedule for future ODF versions to > > > deliver > > > specifications more frequently, and how to lower the time from a > > > first > > > feature proposal to a specification that contains the feature. > > > > > > I don't want to start with too many introductory words, but think > > > a few > > > observation may be reasonable, in particular for those who are new > > > in > > > the TC: > > > > > > - The OASIS TC process defines three levels of approval: > > > Committee > > > Specification Drafts (CSD), Committee Specifications (CS), and > > > OASIS > > > standards. While it of course should the objective of a TC to get > > > OASIS standard approvals for the specifications it develops, a TC > > > may > > > decide to advance a particular specification only to the CSD or CS > > > level. > > > - It takes a minimum of about two months to advance a CSD to a CS, > > > and > > > a minimum of about three months to advance a CS to an OASIS > > > standard. > > > - There is an obligation to submit all ODF OASIS standards to ISO. > > > The > > > ISO standardization process itself takes at least 6 months. > > > - Each specification document requires editorial work (including > > > clarifying last details and issues). A rough estimate could be > > > that for > > > two months specification work, 1 month editorial work is > > > required. > > > - Our TC process is member driven: Individual TC members may > > > propose > > > enhancements for ODF, but they are also responsible for advancing > > > their > > > proposals into a state where enough details are specified so that > > > the > > > proposals can be voted on and integrated into the specification by > > > the > > > TC editors. Which means that it is to a large degree under the > > > control > > > of the TC members themselves when an enhancement is ready to be > > > considered for integration into the ODF specification. > > > > > > Considering all this, it is realistic to assume that we cannot > > > release > > > OASIS standards more frequently than every two years, but even > > > when we would only have a window of about 6 months where we can > > > add enhancements into a specification document. > > > > > > What I'm therefore suggesting is that we > > > > > > a) make use of the CSD and CS levels of approval > > > b) adopt a time-boxed or "train model" where we have previously > > > agreed > > > dates where we aim to have CSDs ready, and where we accept for a > > > CSD > > > only what is ready by when. > > > c) decide for each CSD individually whether we want to get a > > > higher level of approval or public reviews. > > > > > > How could this look like in practice? > > > > > > We may agree that we deliver CSDs every 6 months. This would mean > > > that we would have a phase of 4 months open development where we > > > integrate all proposals that are ready to be integrated, which > > > means that they are detailed enough to be integrated and have been > > > approved. After this 4 months, we would have a phase of two months > > > where the proposals get integrated into the draft. We when vote on > > > the draft, and most likely get a CSD that is published. After the > > > CSD approval, we start working on the next CSD in the same way. > > > > > > When a CSD has been approved, we also discuss and agree whether we > > > want to start a 30-day public review for the draft, and ask for > > > approval as a > > > CS. But even if we do so, we would continue our work on the next > > > CSD. > > > > > > Where are a lot of things to consider for this decision: For > > > instance > > > how much new content we have in the specification. Or whether we > > > have > > > other public reviews running. Or where we are in the approval > > > process of > > > previous specifications. For this reason, it appears reasonable to > > > not > > > set up any rules for this in advance, but to just use the CSD > > > approvals > > > as checkpoints, and to decide individually for each CSD how to > > > proceed. > > > > > > When we decide to advance a CSD to a CS and got the CS approval, > > > we > > > would then discuss and decide whether want to advance it to an > > > OASIS > > > standard. > > > > > > Where may of course be features that need more than four months to > > > be > > > developed. For these, we may set up sub committees, and may > > > consider the > > > deliverable of the sub committee as a proposal that we treat the > > > same > > > way as the other proposals. > > > > > > 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 > > > - The "rush hour" we get when we are getting closer to the end of > > > a > > > feature definition phase is avoided, because if a proposal misses > > > a specific CSD, the next opportunity is already 6 months later. > > > - Assuming that we get comments in particular for new features, we > > > get a > > > better distribution of comments by having many "small" public > > > reviews rather than a single "large" public review. > > > > > > Feedback to these suggestions is of course very welcome. I also > > > did present these ideas at the last OOoCon. The feedback I got > > > there from users of the ODF specification was positive. The slides > > > of the presentation are available here: > > > > > > http://www.ooocon.org/index.php/ooocon/2010/paper/view/233 > > > > > > Best regards, and best wishes for the holiday season. > > > > > > Michael > > > > > > > -- > > Oracle > > 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 > > > > Green Oracle Oracle is committed to developing practices and > > products that help protect the environment > > -- > Oracle > 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 > > Green Oracle Oracle is committed to developing practices and products > that help protect the environment