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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Re: [office-requirements] RE: [office] Re: [office-requirements] Currentstatus

Bob Jolliffe <bobjolliffe@gmail.com> wrote on 07/19/2010 07:48:04 AM:

> So I would suggest that
> (i)  we complete the current process of categorizing current odf-net
> jira issues into thematic areas.
> (ii) we have a roadmap discussion where we can identify some
> milestones of subsequent odf versions.  This might best be done in a
> teleconference which could be done under the auspices of odf-next SC.
> Will it be 1.3, 2.0 or do we converge to the square root of 1.5:
> 1.224744871...  :-)
> (iii) we start pegging the issues from (i) to the proposed versions of
> (ii).  This process could well proceed using the mechanism Rob has
> suggested.

It is interesting to consider a strategy of simultaneously working on two 
versions of ODF:

A) A backwards-compatible, maintenance of ODF 1.2, doing errata, of 
course, but also any urgent feature work that can be done in a 
backwards-compatible way. 

B)A more substantial perhaps release which would have some larger features 

This approach has been attempted before with other standards and there are 
some traps to avoid:

1) The visionary release takes so long to create that market forces push 
more and more new features into the maintenance version and the visionary 
release can't keep up.

2) The visionary release is too much for vendors to implement, and they 
don't adopt it, instead sticking at on the maintenance release.  This in 
turn can feed back into #1 above.

3) The visionary release introduces compatibility problems that lead to #2 

4) The announcement of a visionary release causes adopters to pause and 
wait to see what happens before adopting the standard.  In other words, it 
increases the perceived risk of adoption.

There may be other such risks.  Interesting to look at examples like XML 
1.1 that never quite made it.

Of course, these are risks, not absolute certainties.  There are things we 
could do to make this work.  For example, the visionary release could 
include a modularization effort that allows us to better formula an ODF/A 
for archiving, for example, which would be more suitable for long-term 
document retention than ODF 1.2 or ODF-Next by itself.  And if we're 
careful about only adding features where we have several vendors committed 
to implementing, then we avoid some of the other risks.

In any case, I like your idea of continuing to categorize the ODF-Next 
issues in JIRA.  Is there anything I can do on the admin side to make this 
easier?  For example, are their any "components" that we could add to JIRA 
that would make classification into thematic areas easier?  Or any 
conventions we should adopt?  Do we need to agree on what the themes are?


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