This seems fine to me. For the record, I'd like to confirm that I
believe that an XML notation ought to be a deliverable. My earlier
cautions were rather around the complexity of the data-model that we
define. I really would like to keep it as simple as possible, while
still permitting "expansion" or greater complexity in cases where this
is appropriate. Profiles, or possibly optional elements might be the
simplest way to permit this. However, once again, this is
Durand, Jacques R. wrote:
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
- 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: 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 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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com