I am happy with your proposal.
From: Durand, Jacques
Sent: Friday, December 15, 2006
Subject: RE: [tag-discuss] Charter
talks (formerly: RE: Keep It Simple: some options)
The discussion list has been up for about 1 month, and so far I can say it has
raised a level of interest beyond expectation, for a topic sometimes perceived
as rather abstract and unglamorous...
From what the list shows, we seem to be at a point where a charter can be
drafted with good chances to gather enough support.
NOTE on the charter exercise:
As David reports, OASIS favors TCs with a precisely scoped, well-qualified set
of deliverables (and of activities).
This is largely due to legal matters (new IPR policy).
Given the small number of neurons available for legal matters in my brain, I'
ll try to illustrate the rationale in concrete terms as I understand it:
- if you become member of a TC, your company is legally bound to the TC IPR
mode regarding any output produced by the TC, which means your company is very
much restricted in its use and rights of the intellectual property produced in
the TC deliverables - regardless whether contributed by you or others. So the
narrower the charter scope, the less likely this output will infringe on your
existing or future company IP or patents, and the easier it may be for a
company to adhere to the TC.
So that is why we try to be precise in terms of TC output (and of TC topics of
In terms of charter, abstracting from feedback on this list, here is an option
for what is within scope (process for the TC to produces these, e.g.
serialized/parallel, is left out):
1- a Test Assertion
Guideline (TAG): an English narrative including definitions, abstract model /
structure, methodology and example showing how to extract TAs from a target
2- an XML notation
for the TA model/structure in the TAG deliverable, possibly augmented of an
additional notation (e.g. modeling notation) that may be complementary to the
Note that this is not as detailed as what has been proposed e.g. by David - but
I hope it strikes a balance between the essence of these proposals, and the bit
of flexibility needed in a charter?
From: firstname.lastname@example.org [mailto:email@example.com]
Sent: Friday, December 08, 2006 8:35 AM
Subject: [tag-discuss] RE: Keep It Simple: some options
Maybe the following is agreeable for a charter draft?
1. First the TC would develop an abstract structure for a test
assertion (TA). Back on December 3rd, I sent an example that
three components of a TA: multiple contingencies, one stimulus,
one result. I just made that up to show that components are not
necessarily complex and scary. After having defined components,
publsihing them with a Request For Comments or doing some form of
outreach would be appropriate, but I hesitate to call this a
"deliverable" of the TC.
2. After getting some feedback on the abstract structure, the TC
would issue a document that describes how the structure could be
manifest as English sentences. This would be a deliverable.
3. Either simultaneously with (2) or after, the TC would issue a
document that specifies an XML notation for the same structure.
Among the requirements would be a simple identifier attribute for
each and every TA that allows citation of individual TAs.
Either (2) or (3) would also provide the desirable qualities of any "fixed
wording" parts, which use wording specific to the domain of the spec. In
other words, a set of TAs should share domain-specific words (especially nouns
and adjectives) among the TAs in such a way that similarities and dependencies
Patrick Curran wrote:
>If the TC achieved no more than this (encouraging spec authors to
>create test assertions and defining a simple markup) I would be very
I say that if the expectations are too low, we could avoid having a TC and just
discuss this on a Wiki, then issue something that resembles a W3C Note. I was
talking with OASIS staffer Mary McRae last night at the XML 2006 conference,
and she said OASIS is now favoring TCs with small sets of deliverables, but I
think there is such a thing as too small. I think producing XML that divides
the assertion element into components of some kind is a bare minimum to justify
forming a TC.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com