[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag-comment] Test Assertions for Normative Statements in theebBP v2.0.4 spec
Dear Jacques, Thank you very much for your
comments. It is always very good to have your opinion. The TAB works seems very
interesting to me and the categories seem quite similar to mine. My interest in
the categories in particular is in how to treat them when defining TAs in this
case and in my work when defining the normative statements in the ontological
manner, which to me seems quite similar to defining TAs. Not all the categories
would be possible to define in the ontological manner I believe. Regarding the TAs, now that you
defined them I have a better understanding of them. However, I think it would
be a good step forward if we can base the subject and predicates on a
meta-model of a standard. This, in my opinion, would be another step towards a
test case. As you probably know, I am working
on a methodology for ontology-based standards development. David Snelling might
have already shown it to you. Otherwise, please let me know and I will send it
to you. I would be most interested to know your opinion on the methodology. Best regards From: Jacques
Durand [mailto:JDurand@us.fujitsu.com] Bahareh: Thanks for your interest. Dennis has addressed some of your points
(thanks!) - let me take the time to add a few things: see inline <JD> of your *two* emails below: Hope that helps… Cheers Jacques -----Original Message----- 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). <JD> Hard to get
very detailed on this - what you are asking for is a guide to write
specifications, no less (beyond our scope).... For now we only define: "
[normative statement] A statement made in the body of a specification that
defines prescriptive requirements on a conformance target."</JD> 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. <JD>You may be
close to a similar classification we drafted in OASIS TAB (of which I am a
member): see Data artifacts/State machines/Processors under section 3 of this
wiki: http://wiki.oasis-open.org/tab/TestingPolicy Although our immediate
concern is conformance assessment, these could extend to helping write
normative statements. Feel free to reuse/refine. </JD> 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? <JD>Yes but that
is part of a more ambitious guide I think, beyond testing concerns.</JD> Regards Bahareh -----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: <JD> as you
mention at the end, to be useful the TA should bring us one step closer to the
actual testing. In some cases unfortunately it is not obvious how to do that.
Yet, just identifying clearly the Target, and stating clearly the abstract
true/false property to verify in the predicate, will help the next step –
whether automated or human-performed – more than you’d think. SO let me attempt
to answer yours below (some TAs may appear to provide little benefit, but still
are a step forward in helping whoever will verify later the normative
statement). </JD> P. 29 A document referenced by an include
element MUST be inserted before schema or DTD validation is attempted. <JD>The
condition “before schema or DTD validation is attempted “ may be handled either as a prerequisite, or as predicate: (option 1) -
target=document, predicate=(document has all includes
resolved/inserted), prerequisite=(document is candidate and ready for
validation) (option 2) (in case we
don’t know how to verify “ready for validation”, we rely on predicate to
express the whole scenario that MUST NOT happen for ANY document) -
target=document, predicate=(NOT(document has not includes
resolved/inserted AND document validation has been attempted)) , which is same
as: - target=document,
predicate=(document has includes resolved/inserted OR document validation has
not been attempted)</JD> 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. <JD>Here only
for “receipt”: -
target=(receipt message), predicate=(content of receipt is
reviewed AND legibility of message is reviewed) preprequisite=(receipt is
candidate/ready for processing) -
same comments as for p.29 (could have folded prereq in
predicate) </JD> 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. <JD> That is a
strange normative statement rather high level (general “state alignment”
property predicated on an implementation architecture statement). I think the
spec meant simply “must”, not MUST. </JD> P. 57 When multiple activities are nested
within ComplexBTA, these activities MUST be executed in series. <JD> if we have
an idea of how to observe activity execution e.g. via a trace: Target= ComplexBTA element, Prerequisite=(target is
executed), Predicate=(exec trace for target shows same order for activity
execution as activity elements in target) NOTE: I have made here
an “interpretation” of the original normative statement. This interpretation
(assuming execution tracing) should be mentioned/assumed in the
“normativeSource” element of the TA, i.e. in addition to the pointer to
original statement. </JD> P. 60 Whether BeginsWhen, EndsWhen, or Pre- or
PostCondition, the information MUST be visible to the parties involved. <JD>Also not
sure what is meant by “visible” (i.e. how to interpret it). The target=
these elements, Predicate=(a more concrete interpretation of “visible”) </JD> 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. <JD> In the
absence of a more concrete “interpretation” available for such statement, the
TA will remain abstract: target=BT, prerequisite=(BT is executed),
predicate=(BT outcome = success OR state(party prior execution) = state(party
after execution)) So here at least we
identify the measurable entities: “party state”, BT outcome. Sounds modest, but
is a step forward. </JD> A ReceiptAcknowledgement (if required)
MUST always occur before an AcceptanceAcknowledgement (if required), and an
AcceptanceAcknowledgement MUST always occur before a Response (if required). <JD>target=BTdefinition,
predicate=(no(RA) or no(AA) or RA<AA) and (AA<R or no(R) ) ) </JD> 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. <JD> (only for
the 1st statement here) target=BTdefinition,
predicate=(no(BusSignal) or timeout has value) </JD> 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. <JD>
target=BTexecution, prepreq=( Receipt Exception occurred ), predicate=( Receipt Exception = last event
in the BTexecution) </JD> 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> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]