[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 work).
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 specification.
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 XML notation.
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: email@example.com [mailto:firstname.lastname@example.org]
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 defined
three components of a TA: multiple contingencies, one stimulus, and
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 are visible.
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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org