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


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

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

Subject: Re: [oiic-formation-discuss] Interoperability versus Conformity

It is probably premature to start work on that document.

Let me state again quickly the purpose of this discussion list, since I'm sure there are people who have joined the list recently.

Hopefully we all have a shared goal of improving ODF interoperability. Accomplishing this task in OASIS, an open standards consortium, will require us to perform some formal as well as technical tasks.

The first set of tasks are around formally creating the Technical Committee in which we will accomplish our work.  Until that is done, we don't have IPR policy, we don't have rules of order, decision making procedures, formal membership, voting, formal documents, ability to participate in OASIS interop demos, ability to liaise with related standards groups, ability to take advantage of OASIS-hosted document libraries, wikis, etc.  We're just a group of interested parties discussion the creation of an OASIS TC.  We're the patriots gathered at the Old South Meeting House.  We're not Congress.  Nothing wrong with that.  This is just step 1.  

The discussions we're having now has a single formal purpose, as well as an informal purpose.  The formal purpose is to agree on a proposed TC Charter for a new OASIS TC that will help accomplish our mutual goals around ODF interoperability.  The informal purpose is to socialize the idea of such an Interop TC and to hopefully persuade some of you to participate in the TC, once it is created.

A TC Charter in OASIS limits what the TC can do.  The Charter is voted on, and hopefully approved, by the entire OASIS membership, not just the members of that TC.  We don't want the charter to be so broad that we appear unfocused or unlikely to succeed.  But we don't want it to be so narrow that we cannot accomplish our goals.  In particular, we will likely need to do some investigatory work in the TC to determine what the main interoperability issues in practice actually are and to prioritize our deliverables accordingly.

It is probably useful to take a look at some other OASIS TC charters to see their general form level of detail.    If you go to this page you'll see all the OASIS TC's:  http://www.oasis-open.org/committees/committees.php

Click on any one of those TC names and you'll me taken to the TC's home page.  Each TC will have a link in the upper right corner called "Charter" that lists their charter.

So step 2, once we agree among ourselves on a TC Charter is to formally submit this to OASIS (along with the initial membership list) and ask for a new TC ballot.  OASIS staff would then examine our charter, ensuring that it was in the proper form, etc., and then set up an electronic ballot of the OASIS membership to approve.

If approved, then we are on to step 3, which is to have our initial meeting, elect a chair or co-chairs, secretary, etc., and formally start our work.  It is at that point that the real technical work starts,

So if we back up, back to your interest in ACID-style tests, I think the way forward would be something like this:

1) Make sure everyone on the list is familiar with what an ACID test is.  I know many of us are familiar, but it is probably good to send out a link to it, and explain what is attractive about that approach and how that would relate to other testing approaches.

2) Propose that we have an analogous kind of test for ODF.   Formally we probably want to say something other than "Acid test".  Maybe something like, "A test document that exercises complex interactions of ODF features in a way which gives a quick qualitative indication of conformity"?  Is that what we all mean by an Acid test?

3) Ensure that the proposed charter calls this requirement out.  Specifically, propose to include it in the list of deliverables, and ensure that the scope statement is broad enough to permit it.

In particular, I don't think we want to define the exact contents of the Acid test on this list.  That is a task for the TC to do.  Or alternatively, if any individual or subgroup of this list has an urge to tackle one of these tasks immediately (I know the feeling) then you can certainly do that, and that could be later submitted to the TC as a contribution.  We would mention that then in question (2)(g) "Optionally, a list of contributions of existing technical work that the proposers anticipate will be made to this TC".  But I think I'd want the technical discussion of that contribution to occur off-list.



"Matthew Reingold" <matthewreingold@gmail.com> wrote on 06/11/2008 10:51:31 AM:

> I think making a google document for people to add in things
> suggested for the acid test is in order!
> copy that link to edit the document IF this method is acceptable
> (per Rob) to make a draft of requirements for an Acid test.
> I'm creating a mostly blank google word doc, maybe we can all edit
> it (I think the limit is 50 editors at once and 150 viewers or
> something)....it can be edited via the link I provided. It will
> update realtime with the editors, so everyone can contribute their
> input simultaneously.  It seems to me to be the easiest tool to use
> for collaboration.
> Rob, please shoot me an email if you'd like me to remove this in
> case this is not a method you'd like to use in order to edit the
> document. I don't want to do this in any way you'd find
> inappropriate, just wanting to help.

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