Re: [tamie] Requirements: Clarification of Use Cases

[stephen.green@systml.co.uk]

Another example:

a security certificate expires during testing or monitoring

Which reminds me: what are the implications on testing
and monitoring of the ranges of attribute values which express
security requirements such as those for more than transient
security in ebXML protocol and process artefacts

- e.g. if there is a requirement that encryption, say, be assured
perpetually for the message would this preclude the testing of the
encrypted message content as part of the test suite (such as any
tests of process requirement predicates dependant on XPaths which
if evaluated would require the persisting of decrypted content)?

-- 
Stephen D. Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

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



Quoting stephen.green@systml.co.uk:

> I was asked to clarify the use cases behind some of
> the requirements I recently proposed for TaMIE
> deliverables.
>
> I'll list a few examples in no particular order.
>
> A.
> Sensitivity to changes in message structure, message semantics
> and business process/protocol definition artefacts - perhaps
> changes triggering events which affect testing and monitoring
> in some way (such as to say that outcomes are no longer valid
> or evaluations must be updated in a predetermined way).
>
> Business Process/Protocol changes
> 1. use case: a time to perform attribute in a business process
> definition is increased to cater for increases in latency during
> a holiday period
> either (not necessarily in conformance to best practices):
> a. a process definition version is updated and a CPPA is
>    correspondingly updated to include the new process and the
>    a the message header change occurs to include the new CPPA
>    service ID
> b. a process definition timestamp changes and yet no change is
>    made to the CPPA or message so an exception might have to
>    be thrown to say that we no can no longer assume that the
>    originally known time to perform, etc still apply
>
> 2. use case: as for 1, above, but after the holiday period the
>    time to perform is somehow reverted back to original value
>
> Message structure/semantics changes
> 3. use case: the value of tax legally applicable in a business
>    document (such as sales tax in an invoice) changes due to a
>    change in the law
> Either
> a. the code used in the tax entity of the document stays the same
>    and the semantics of the code as defined not in the schema but
>    in an adjunct codelist document (such as genericode) changes
>    and this is visible to the monitoring by the change in either
>    the timestamp of the codelist document and/or the version ID
>    part of a process definition external document definition
>    reference ID. The validation of the document then is required
>    to change since verification of tax calculation is made part
>    of the validation of the document as a predicate to the type
>    of response document
> b. the validation of the document is again required to change but
>    this time due to the inclusion of a new code previously invalid
>    but now valid. This code is added to a (genericode, say) file
>    of valid codes which is used during validation of the document
>    but either the file timestamp or 'last modified' date changes
>    or the version ID changes. In either case there is an event to
>    indicate that previous tests or codes are no longer valid.
>
> There are many variations possible in the details of these use cases,
> such as how monitoring would have to adapt to changes, if at all,
> and what would be required to happen when a change event occurs.
> If schemas are updated then it might be a requirement a) that the
> new schema be used in validation or b) that monitoring stop or tests
> be invalid until manual changes of schema used for validation are
> made. If schemas are the same but adjunct files like codelists or
> business process definitions are changed then it may be unrealistic
> to expect that such complex and unpredictable changes could be catered
> for without re-generating or perhaps re-authoring the test suite but
> it might still be necessary to have an event occur and be responded
> to which indicates that testing might no longer be valid and human
> intervention is required.
>
> Other areas where there might need to be senstivity to changes in
> definition artefacts:
>
> mapping requirements between one document syntax and another
>
> change of version of definition syntax itself (e.g. XML Schema 1.0
> changed to XML Schema 1.1 without change to document structure,
> use of XML 1.1 rather than 1.0, BPSS 1.0 definition upgraded to
> ebBP 2.0 without a change to business process)
>
> change of version of ebMS header without changes to CPPA definitions
>
> Would such changes require that testing be updated? What events
> would be appropriate if there is such a change during ongoing monitoring?
>
> Maybe I'm way off target with all this - these are just early thoughts.
>
>
>
> -- 
> Stephen D. Green
>
> Partner
> SystML, http://www.systml.co.uk
> Tel: +44 (0) 117 9541606
>
> 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.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php