Re: [tag] Referencing external test assertions

[Kevin Looney <Kevin.T.Looney@Sun.COM>]

Hi Stephen,

    This is a good question to bring up.

     I'm not aware of any rules here, but it seems like a 'convention' 
(or guideline) would go a long way for TA organization or Tool 
processing.  This issue seems fairly similar to TA naming, which we also 
gave guidelines/conventions - so I'm guessing we should treat this 
similarly.

The example you gave seems logical (concentric owning sets, separated by 
dots). Perhaps one of the identifiers (probably the outermost one) needs 
to be a symbolic representation of the Spec Name / version / revision / 
date.  Then again, we may wish to refer to TAs from specs, where the TAs 
live over multiple versions (so specifying version / revision / date is 
not important).

Regarding 'import',  this may be important for a schema.  For the spec 
itself, it seems like a well formed specification should describe (in 
some sort of references section) where it refers to behavior / 
conformance from another spec.  Likewise, an analysis should probably 
describe some sort of reference too.

Just some thoughts off the top of my head.
Kevin L


Regarding
Stephen Green wrote:
> Re: Referencing external test assertions
>
> Questions:
>
> Given that I have a set of TAs in an upper level TA Set
> in an instance file/document, how would I apply a set
> of prerequisites to these TAs as a whole or individually
> using the Test Assertion Markup Language? Is there
> any special construct or best practice I would need to
> clarify unambiguously that the TAs (referenced by their
> IDs and the TA Set IDs e.g. 'TASet1.TASet2.ta0001')
> are to be found in a certain file? Do we need some kind
> of construct in the referring instance like an 'include' or
> 'import' statement/element? How is this done in other
> TA methodologies/languages? Would it be something
> new/untested for TAML if we added it? Could tools handle
> such a construct properly? What issues might there be?
>
> Best regards
> ---
> Stephen D Green
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>