[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: TAG discussion list, a status
|
Hi,
Jacques: I have read through your statement.
Please see my comment as following: 1- a test assertion model: how
general can it be? Should we claim applicability to * all* OASIS specs?
Can we identify different categories of specifications or standards? (e.g. XML
mark-ups, message protocols, horizontal vs industry-specific) How do we
position this guide with cases where TAs can be automatically generated from the
spec material? Lin Ju Comments: I think the TA model should be as "general" as
possible. Otherwise, it will lose the sense of our initiative. The general TA
model should guide all and we can cooperate the different categories of
specs. <JD> tend to
agree ¨C a ¡°top model¡± J should be
provided. With a good set of well-rounded examples, hopefully users can relate
this model to their own specs. Categorization may help them do
that. 2- Can we reconcile generality with
providing enough guidance and details for writing TAs in various conditions?
Should the abstract model be ¡°branched¡± into more concrete sub-models more
appropriate for different types of tests / types of
specs? Lin Ju Comment: If the model is branched into sub-models, we will
get into more individual special case. I think if possible, we can use the
different types of tests as example to prove TA abstract model and guide
the user to apply our model. <JD> I just
repeated your answer in my previous answer¡ so we seem to agree
;-) 3- the scope of the deliverable,
i.e. content of the guideline: what should the guideline cover besides a TA
model. In particular, should we consider a TA XML mark-up? (some orgs have
already done that and will do: WS-I) If yes, what kind of use should we support
for such a mark-up? How much space devoted to
examples? Lin Ju Comments: The guideline which cover the TA model and we can
use XML mark-up as example to support our TA model. In this way, we won't create
conflict with WS-I. And also, it will prove TA model can be much more
general. <JD> some of us
may expect our group to produce a ¡°normative¡± mark-up. We¡¯ll discuss
this¡ 4- how to cooperate with other orgs
(W3C, WS-I¡) in order to produce a guide that is consensual beyond
OASIS. Lin Ju Comments: Up to now, i have been looking at the W3C's test
assertion guideline. Just like what you have said, they already have the brief
in the very short general term. I think if we all put the effort into this TA,
we should create the TA which can be exceed the W3C's guideline. After all the
completion, we can submit this to W3C. <JD> makes sense
¨C I know Lynne has been involved in drafting the W3C guide earlier this year, it
happens that the W3C QA interest group has other priorities right now. Which is
not bad: that gives us reasons to start an 100% OASIS initiative on this without
worrying too much of aligning work with parallel external efforts. In a second
phase it is my intent to get a common guide doc at some point across orgs.
¡ Lin Ju Comments: The obstacle which i can see right now is we have
to be familiar with the current OASIS individual spec. In order to give the
general guide and provide the example for them, we have use our group's
individual expertise to provide all these information.
<JD> Indeed, we
may have to not just look at specs, but also talk to some folks from other TCs,
to extract at least 1 or 2 TAs from them. It is particularly important that we
do a good ¡°public relation¡± job so that our work is well publicized and accepted
by other groups ¨C rarely will a TC output be as ¡°generally applicable¡± and
cross-areas as ours¡ I suspect that what we have to learn from a look up
of OASIS specs, is not so much how to build the top model, but refining the
methodology rules for deriving TAs from the model for spec X or Y
. Lin ************************************************ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]