RE: [tamie] Updates on lts xml for input to script compiler, some questions about monitoring for condition guard values...

["Jacques R. Durand" <JDurand@us.fujitsu.com>]

I knew at some point we would have to tackle how TAG and TaMIE relate to
each other... My $0.02 below:

At first sight, TAG comes before TaMIE: as Stephen said, test assertions
can be used to give a precise definition of what conformance means (e.g.
associated with a conformance profile), and to serve as a blueprint for
to-be-developed test suites that will verify that conformance. These
test suites can then take advantage of TaMIE scripting.

Where things get blurred, is when (in a future work) TAG test assertions
are themselves coded with Xpath - as in WS-I. In that case, test
assertions become also test cases, and clearly in some cases one could
have hard time deciding which one to use to script test cases: (a)
TaMIE, (b) TAG + its Xpath "profile".

For example, it is clear to me that WS-I test cases could be scripted
both ways. However, some of these test cases are about particular
sequences of messages (sequence of events) and it is a bit tricky to
code these using a single declarative Xpath expression, as required by a
test assertion. (XPath2.0 does the job, but not XPath1.0). A test
assertion is a declarative statement (no notion of workflow), while a
TaMIE script is a state machine, which is more appropriate when what is
to be monitored is itself a "flow" (even if mapped into a single XML
doc).

But as far as conformance is concerned, test assertions (TAG) is the
proper way to express it (or to start from) while remaining close to the
spec, and making abstraction of test execution details. I am not sure
how TaMIE scripts couldbe derived automatically from TAG, as clealrly
there is more info in a TaMIE script than in a T.A., unless some
specific & additional domain context is provided.

-jacques

-----Original Message-----
From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On
Behalf Of Stephen Green
Sent: Friday, March 20, 2009 6:46 AM
To: Moberg Dale
Cc: tamie@lists.oasis-open.org
Subject: Re: [tamie] Updates on lts xml for input to script compiler,
some questions about monitoring for condition guard values...

Dale,

If TaMIE would be the right place for looking at how to create TAG test
assertions which can be transformed into ETSL (eTSM) scripts then it
does look feasible that all the suitable information for test assertions
can be extracted into TAG test assertions from an ebBP document.

What that would then mean about conformance? I would say (Jacques'
opinion really needed here to verify this or otherwise) 1. the test
assertions would help with conformance testing if we decide that what we
are testing is 'conformance'
2. the test assertions would equally (perhaps more so) help with
interoperability testing - if we decide that what we are testing is
interoperability The question then is (I think): Are we aiming to ensure
that two implementations are 1. conformant to an ebBP def (etc) or 2.
valid according to an ebBP def to the extent required for the
implementations of the process to interoperate? Maybe the answer doesn't
affect too much what we are doing though. Maybe we are to cater for both
possibilities (if they are different). This is really what I'm asking:
Is the use case 'uc3' about conformance to a process (as defined by e.g.
an ebBP definition or other process definition based on labelled state
transitions) or is it
about using an ebBP (or other standard document) to test for all those
things defined by the ebBP which are required for interoperability or
something else?
Maybe all three.

Best regards

Steve

2009/3/19 Moberg Dale <dmoberg@axway.com>:
>
> Dale, (asks Stephen)
>
> Just to seek clarification of what might seem obvious - I gather the 
> goal is to treat an ebBP as being a kind of test assertion (or set of 
> test assertions) about the collaboration(s). Is that
> right: Are we aiming to test the exchanges for conformance to the 
> ebBP?
>
> <Dale>
>
> I actually wondered whether the way to proceed would be to transform 
> the BP into TAG style assertions. That might also be possible. I have 
> not followed up on that question; is there a standard way to take TAG 
> and end up with ETSL? If there is, I suspect that there might be a way

> to XSLT our way to TAG style assertions.
>
> I think TaMie is trying to see whether the events on the board provide

> an "execution trace" for a process. If the events do that, then the 
> events would conform with the process model (or selected aspects of 
> it) specified by the ebBP.
>
> If by "conformance" you mean to say something about the
> implementation(s) that are producing events, there may be quite 
> different approaches to assessing whether the implementation conforms 
> with the specification.
> I am not certain that gathering an execution trace (or even many of
> them) establishes conformance with the specification.
>
> Validation of the implementation (with respect to a specification) 
> drifts more into "proving" that under whatever conditions that satisfy

> the implementation's description are ones where the traces that are 
> produced are ones that satisfy the specification. Often these 
> derivations require reasonably powerful logics (with mathematical 
> induction support, for example, possibly over "big" ordinals) But I 
> digress.
>
> In TaMie, we are testing or verifying implementations for conformance,

> but not validating them (which in accordance with some linguistic 
> communities, would need something like a derivation of the 
> specification assertions from some properties of the 
> implementation...)
>
> Anyway, I think I would need to understand your usage of conformance, 
> and also clarify what is being said to conform with what, to be 
> confident that I am addressing your question. I am afraid my brain is 
> a bit too cluttered with a bunch of distinctions to provide a simple 
> straightforward response.
>
> Maybe a discussion on the call would help?
>
> </Dale>
> Secondly, is there anything else we would want to test using the 
> derivatives of the ebBP? Perhaps in combination with some other 
> configuration documentation - such as business criteria (like no 
> orders being over 1000 USD) - or is that out of scope for uc3?
>
> <Dale>
> It seems to me that we could add test assertions for business rules 
> connected with the specifics of the collaboration. Certainly worth 
> investigating.
>
> But these rules would not in general be extracted from the ebBP 
> (except that the timeouts are associated with how long an "offer" is
extended.
> Monica M or Jamie C can elaborate on how these business/tort law sorts

> of considerations are partly captured in ebBP) UNCEFACT (TMG maybe?) 
> used to have an initiative for capturing BRs of the sort you mention 
> (real TPAs) but I am not certain the group completed a full ratified 
> open development procedure.
> <Dale>
>



--
Stephen D. Green

Document Engineering Services Ltd



http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice

---------------------------------------------------------------------
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