RE: [tag-comment] Test Assertions for Normative Statements in theebBP v2.0.4 spec

[Bahareh Heravi <Bahareh.Heravi@brunel.ac.uk>]

Hi Denis,

Thank you very much for your response.

I believe there should possibly be a guideline for defining normative statements themselves, if already doesn’t exist (I am not aware of such thing). If it does exist, I guess there are rooms for significant changes / improvements. Furthermore, I am thinking of categorising the normative statements, so that we may employ different scales and measurements for them. By category, I mean something different to their prescription level. Now I can think of some categories: 

-	Static: which are mainly about well-formedness rules and relationships between classes / entities / concepts.
-	Dynamic: which are mainly concerned with state management and transitions. This is a bit tricky! Especially in ontology world that I am working in.
-	Run-time: the ones which should be handled by the implementation, BSI in case of ebXML. 

If we can distinguish the types of the normative statements, it might be easier to think of ways of measuring the conformance of an implementation or an XML document to a specific spec.
What do you think?

Regards
Bahareh

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: 01 March 2011 20:13
To: Bahareh Heravi; tag-comment@lists.oasis-open.org
Cc: david.snelling@uk.fujitsu.com; JDurand@us.fujitsu.com
Subject: RE: [tag-comment] Test Assertions for Normative Statements in the ebBP v2.0.4 spec

This is an useful question.  It is probably something that could be dealt with in the Guidelines document.  I speculate (and do not speak for the TAG TC) for possible clarification of your questions:

I think the question to ask in framing a test assertion and its predicate is, "What about the normative requirement is something that can be inspected for?"  A test assertion is about the inspection of one such aspect of a requirement.   That is, what are observable, measurable, or simply reported on?

In some cases, this reveals a deficiency in the normative language itself.

In other cases, when it is about behaviors that are prescribed to happen with no means of specifying how the provision might be enacted, the predicate may be that someone attests to the provision being satisfied (or not).  That is, "inspection" amounts to confirming that such an attestation has been provided.

For example, specifying that a requester MUST NOT remain in an infinite wait state (your p.76 example) would appear to imply that there be an identifiable procedure by which a requester avoids doing that (although it is a bit like saying a process must not crash and can never hang).  Failure modes are always tricky to deal with and their provision in specifications is often problematic, which is why that particular example caught my eye.

One could also consider a suite (2 or more) test assertions based on a single broad provision, where coverage of cases might involve inclusion of some test assertions where the current specification is underspecified to a degree. Hence such assertions, if introduced in the suite, might be informative and relevant to achievement of interoperability under failure conditions but not be material to assertion of conformance simply because that is not addressed by the provision). 

 - Dennis E. Hamilton

-----Original Message-----
From: Bahareh Heravi [mailto:Bahareh.Heravi@brunel.ac.uk] 
Sent: Tuesday, March 01, 2011 07:16
To: 'tag-comment@lists.oasis-open.org'
Cc: 'david.snelling@uk.fujitsu.com'; 'JDurand@us.fujitsu.com'
Subject: [tag-comment] Test Assertions for Normative Statements in the ebBP v2.0.4 spec

Dear All,

 

I am trying to define some Test Assertions for the ebBP v2.0.4 spec. However, in some cases it doesn’t seem possible for me to do so. I have found quite a lot of Normative Statements, which I couldn’t define a TA for. A number of such normative statements are as follows:

P. 29
A document referenced by an include element MUST be inserted before schema or DTD validation is attempted.

P. 47
If specified, the content of the receipt and the legibility of a business message (if required) MUST be reviewed prior to the processing of the Requesting or Responding Business Document or the evaluation of condition expressions in the message's Business Documents or Document Envelope.

P. 49
However, to achieve this result (state alignment), the Business Transaction protocol MUST be implemented on top of a reliable messaging service that provides guaranteed message delivery at the transport level.

P. 57
When multiple activities are nested within ComplexBTA, these activities MUST be executed in series. 

P. 60
Whether BeginsWhen, EndsWhen, or Pre- or PostCondition, the information MUST be visible to the parties involved.

P. 69
The Business Transaction is an atomic unit of work. All of the interactions in a Business Transaction MUST succeed or each party MUST revert their state to the state prior to the start of the BTA.

 

A ReceiptAcknowledgement (if required) MUST always occur before an AcceptanceAcknowledgement (if required), and an AcceptanceAcknowledgement MUST always occur before a Response (if required).

P. 76
A timeout parameter MUST be specified whenever a Requesting or Responding party expects Business Signals in return to the Business Document Request or Response. A Requesting party MUST NOT remain in an infinite wait state.

P. 77
A Receipt Exception signals an error condition in the management of a Business Transaction. This Business Signal is returned to the initiating activity that originated the request. This exception MUST terminate the Business Transaction.

 

I can imagine of defining some TAs which are not that close to the test case and are not based on any meta-model, which I don’t think would be of much use. An example would be something like the following:

 

 

TA id: ebBP-P47

Normative Source: specification requirement zzz

Target: business message

Predicate: content of the receipt and the legibility (perhaps to be defined in another TA) [of a Business Message] to be reviewed prior to the processing of the Requesting or Responding Business Document or the evaluation of condition expressions in the message's Business Documents or Document Envelope.

Prescription Level: mandatory



This doesn’t seem much useful to me and is not that much more formal than the text in the spec. I understand that I have probably not defined it exactly the way I should have, but still I don’t think this normative statement could be formalised in an appropriate way and based on a defined meta-model.

 

I would appreciate if you could let me know the way you would define TAs for the above normative statements. Or perhaps TAs could be only used for certain types of normative statements?

 

Many thanks and Best regards

Bahareh

 

----------------------------------------------------

Bahareh R. Heravi

Doctoral Researcher

Department of Information Systems & Computing

Brunel University 

Uxbridge, Middlesex, London, UB8 3PH, United Kingdom. 

Web: http://people.brunel.ac.uk/~cspgbrh <http://people.brunel.ac.uk/~cspgbrh>