[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag-discuss] the role of an XML mark-up for TAs
hi, see inline.
-Cho From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] Sent: Wednesday, November 22, 2006 5:32 AM To: Lin Ju; tag-discuss@lists.oasis-open.org Subject: [tag-discuss] the role of an XML mark-up for TAs >Lin Ju Comments: The
guideline covers the TA model and we
can use XML mark-up as example. >I think that a TC should
only be formed if it intends to produce a design for
> machine- processable
test assertions, > dp: Not all
wanted testing is automated. Manual intervention is often necessary
> in order
to fully test an object, There seems to be
support on this list for having an XML mark-up within scope of the TA guide
work. But the expectations
placed on this mark-up are not clear yet… I think it is worth spending some time
on it – because if a TC is chartered there will be IPR implications on the
status of this mark-up. I like to think about
it from the viewpoint of what it could be used for. I see three options so
far: 1. methodology helper - Just an XML binding to
the TA model as good as any other, that provides users with a more
concrete framework to write their TAs (i.e. part of the methodology support). A
kind of methodology-supporting script. Not necessarily
normative. 2. publishing source - Like (1), plus it is a
normative representation mostly intended for display and HTML publishing, i.e.
it is expected that XSLTs will be made available and reusable for it. Pretends
to be THE publishing source format. 3. Test suite driver - Like (2) , plus it is designed to actually be processed by test tools. The mark-up will allow for grouping TAs in units that could control the execution of test suites. Note I am not saying these TAs are executable: there will usually be a need for an additional set of * test cases* that is executable – but the TAs would be used as a high-level representation of a test suite, both human-readable and machine-readable, indicating which related test case must be executed, and possibly defining execution outputs more precisely, e.g. error messages.
In the ebMS 2.0 KorBIT testbed, we used XPath for representing TAs. However we experienced with incapability of XPath in representing full TAs, for example, for comparing 'expiration timestamp' with the current time. Because XPath cannot support the functionality, we had to hard code to deal with it.
In the BOD guideline KorBIT testbed, we used JESS for representing TAs. Although we managed to extract many test cases from KIEC guideline, I do not think that a spec write can do it. It was a tough job.
Based on the statements, we really need a new mark-up. 4.
Other? So the design of a TA
mark-up may vary depending on these. Also, the grouping of TAs in larger
entities (e.g. conformance profiles or levels) is another aspect of the mark-up,
that is more or less important to address depending on above options.
I’d like to hear what
people think is more useful or what above option they would consider worth the
work. E.g. do you consider (3) the only worthy goal? Or is achieving (2)
or (1) equally useful? Thanks, Jacques |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]