Thanks for clarifying Rob.
I think that your comments on the Acid Test are on the mark, though it could be preferable to capture the enthusiasm now rather than stifling/deferring it as (provided we are careful with IPR) this could be specified in the charter and incorporated by the TC. The Acid Test should be an ongoing effort rather than a one-time task, likely linked to audience requirements moreso than spec releases. It should be possible to initially generate a test for common usage scenarios and raise the bar with each test release, with a complete test for the latest version of ODF specified as a TC deliverable in addition to a more rigorous test suite.
The moniker 'Acid Test' presumably stems from litmus test whereby a result is quickly and simply obtained, and I think is important both to demonstrate the purpose and to differentiate from a more rigorous quantititative suite which would appeal to decision makers & third party certification labs. The Acid Test would be more interesting then to end users, media and as a result, vendors.
Accordingly I have set up a separate site where we can capture such contributions and which can outlive this transitive list if need be at:
http://sites.google.com/a/odfiic.org/acid/
Thanks Matthew for putting (virtual) pen to (virtual) paper already over here (published here for those who have not yet requested accounts). Perhaps we can still keep a thread on the topic running on the list.
Finally, perhaps we can demonstrate the TC charter by example (even if there are optional sections missing that we will likely adopt):
OASIS Open Document Format Adoption Technical Committee (ODF Adoption) TC
The original Call For Participation for this TC may be found at http://lists.oasis-open.org/archives/tc-announce/200602/msg00020.html
The charter for this TC is as follows.
Name
OASIS Open Document Format Adoption Technical Committee (ODF Adoption) TC
Statement of Purpose
The OpenDocument Format for Office Applications (OpenDocument) OASIS
Standard defines an XML schema for office applications and its
semantics. The schema is suitable for office documents, including text
documents, spreadsheets, charts and graphical documents like drawings
or presentations, but is not restricted to these kinds of documents. It
defines suitable XML structures for office documents and is friendly to
transformations using XSLT or similar XML-based tools. There are
several commercial and open source applications available based on the
OpenDocument Format, with more currently under development.
The purpose of the OASIS OpenDocument Format Adoption Committee is
to create awareness and demand for a new class of applications and
solutions designed specifically to support and leverage OpenDocument
XML. The Adoption Committee will dedicate its energy and resources to
create wide scale understanding of the benefits of OpenDocument format
support within organizations and governmental bodies through education
and promotion. The Adoption Committee will align and support the
activities of the OASIS OpenDocument Technical Committee by providing
market-based requirements. These requirements will help guide future
development of the OpenDocument specification by the OASIS OpenDocument
Technical Committee.
By advancing the adoption of OpenDocument within OASIS, the Committee members:
collaborate within the security of the OASIS open process;
maximize message credibility by working on behalf of a vendor-neutral standards consortium;
build on existing market awareness of OASIS as the home of OpenDocument;
leverage the combined resources of all participants;
coordinate closely with the existing OASIS OpenDocument TC development team;
reinforce OpenDocument as the result of an open, transparent
process guided by multiple vendors, communities and individuals; and
openly share content, and coordinate program execution with other
entities that share a common or similar statement of purpose on a
worldwide scope.
Working together, members of the OASIS OpenDocument Format Adoption
Committee will provide expertise and resources to educate the
marketplace on the value of the OpenDocument format, increasing the
demand for ODF-conforming products, and expanding the OpenDocument
community of users, suppliers, and developers.
Scope of work
With the support of OASIS staff and in accordance with the OASIS
Media Relations Policy, the Committee will assist in coordinating press
and analyst relations such as briefings, releases, and announcements.
The ODF Adoption TC will coordinate communications to the OpenDocument
community through the OASIS and XML.org websites, collateral,
newsletters, webinars, conferences, and other outreach venues.
In cooperation with the OASIS OpenDocument TC, the OASIS
OpenDocument Format Adoption Committee may create white papers, FAQs,
overview documents, case studies, user scenarios, and other educational
materials. The Committee also may establish liaisons in accordance with
the OASIS Liaison Policy with other organizations, government agencies,
and academic institutes concerned with office applications to broaden
awareness of OpenDocument. The Committee may also assist in
coordinating the promotional efforts of members relating to
OpenDocument, leveraging those activities wherever appropriate. The
Committee may work on proof-of-concept demonstrations to showcase how
the OpenDocument Format can be integrated with other standards, for
example using ODF, XFORMS, UBL and various Web service standards built
using specific industry vocabularies, schemas and/or transaction sets.
This Committee will consist of volunteers from member organizations
and will conduct teleconferences and occasional face-to-face meetings.
List of Deliverables
Anticipated deliverables with target delivery dates include:
XML.org OpenDocument Focus Area (3Q/2006)
White papers (3Q/2006)
Position papers (3Q/2006)
Case studies (4Q/2006)
Presentations (3Q/2006)
Webinars (3Q/2006)
FAQs (3Q/2006)
Proof-of-Concept demo scenarios and templates (4Q/2006)
The XML.org OpenDocument Focus Area will be governed by an editorial
board to be established by this committee and consist of members of
OASIS. Content will include works created by the Committee, links to
other third-party works, a wiki where users can contribute to a
collection of best practices, forums, and other applications.
IPR Mode
RF on Limited Terms
Anticipated Audience/Users
We anticipate the work of the OASIS OpenDocument Format Adoption TC
will be used by a number of groups to learn more about OpenDocument:
End users
Corporate and governmental decision-makers
Software Developers
Potential members
Media and industry analysts
Language in which the TC will conduct business.
The TC will conduct its business in English.
On Wed, Jun 11, 2008 at 6:33 PM, <> wrote:
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" <>
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.
>
>
