Some more desirable features

[Jacques Durand]

From the most useful to the less urgent:


- Feature Name: Default ID scheme.
- Description: currently, users must provide an ID scheme (target/
@idscheme) for each target type (target/@type). But in some cases,
there is no convenient way to identify an XML fragment target of a TA,
other than by its position in the document (e.g. root/aaa[1]/bbb[4]/ccc
[2]). In the absence of explicit ID scheme, tamelizer needs to use
such a default ID scheme (as the ability to uniquely identify targets
is key to the test engine, not just a way to identify targets in test
reports).

- Feature Name: TA inheritance.
- Description: currently, TAs need to specify a path value in their
<target>. The TA applies on any instance matching its target path.
But in some cases a TA must apply to a larger set of instances of
different target types. In such cases, it is often the case that these
target instances are all instances of a target “super-type” in
addition to their own target type. E.g. we may have target types
“widget” and “gizmo”. Both are subtypes of “device” target type. We
may have TAs associated with “device” targets, that we want to be
inherited by widget instances as well as gizmo instances. The “cheap”
way to support this (i.e. avoiding to specify something like an object
model out of the TA itself), is again inline “hints” like prefixing
the types with their supertype: <target type=”device:widget”>…</
target>. This annotation tells the test engine that any widget
instance must also be the target of the “device” TAs. The “device” TAs
may or may not specify a path in their target value.

- Feature Name: Richer, processable results for TAs.
- Description: At this time, a TA produces for a given target a test
result which is roughly made of: (1) a standard outcome (pass / fail /
etc.), (2) a diagnostic info. When referring to a TA result from
inside another TA (e.g. prerequisite), only (1) is referenceable, e.g.
<prerequisite>TA123 = ‘pass’</prerequisite>. But in some cases, one
wants to condition the execution of a TA based on more detailed
outcome of the TA, e.g. a variable value. So the feature is about
adding additional output to a <report>, that would be referenceable.
E.g.: <report label=”pass” vars=”myvar1,myvar2”>…</report>. The @vars
attribute would report a more formal output (a sequence of var values)
not visible in the test report (unless the “report” element outputs
them using the taml:eval() function) but usable in other TAs, e.g.:
<prerequisite>TA123($target) = ‘pass’ and TA123($target).myvar1 lt 50</
prerequisite>.