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

[robert_weir@us.ibm.com]

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.

Regards,

-Rob

"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!
>   http://docs.google.com/Doc?id=dgf4kr8g_19c3r6k6f2&invite=fprx8z2
> 
> 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.
> 
>