Thankyou Matthew,
As you know all contributions are gratefully received.
We will review these rules at the next VWG meeting, which given SIBOS
next week will be on Tuesday 9th October.
Cheers,
Simon
Matthew Rawlings wrote:
Dear VWG,
Please find attached a
proposal for 11 additional validation
rules for Contracts messaging.
These rules close out
many ambiguities in processing the
Contracts messages. Andrew Parry is the original author of the
Contracts
messages, and so we should review with Andrew the additional validation
rules.
Matthew
Rawlings
+44 791 539 7824
FpML 4.4 Validation Rules -
Rules for
Messaging
This section is
the constraints that
implement the Business Process definition and Messaging definition in
the FpML
4.4 Working Draft.
These constraints
apply to the
set of all known messages to validate the Business Process and
Messaging
definitions. The rules are tested by applying to the collection of all
messages
available, both sent and received. Each message is referred to as a
“document”,
as this meets the requirement to use XPath 2.0 for paths.
The constraints
are written as
invariant rules that return “false” when they are failed and “true”
when they
are satisfied. The constraints are written to accommodate the open
world
assumption that there may be other messages that are not yet known
about. For
example messages that have not yet been sent or arrived are unknown.
A subset of
constraints is
identified as “Warnings”. These constraints are used when knowledge
from a
message is expected but absent and it is impossible to distinguish
between the
messages being incorrect and the message not yet being known about. For
example
a Request might not yet be known about to match to a Response.
The constraints
that are not
“Warnings” are termed “Mandatory” constraints, which is consistent with
all
other rules.
Content
Rules
Unique contexts:
Functions
The Validation
Functions factor
out common comparison functions for FpML complex types. Many
comparisons can
work using built in XPath 2.0 comparison operators and functions, but
where
FpML has custom types a function may be needed.
The Validation
Functions are
only used when specific rules reference them. The functions do not
change the
context nor the nodes supplied to them. The order of parameters will
always be
stated in the rule where it is significant.
Function:
ContractIdentifierEqual($contractId1
as ContractIdentifier, $contractId2 as ContractIdentifier)
as xs:boolean
The result is true where any
$contractId1//element(*,
ContractId) correlates to any $contractId2//element(*,
ContractId). The comparison function
for correlation
is fn:deep-equal().
Context:
collection()
Every /FpML/header/messageId must be unique. The
comparison function
is fn:deep-equal().
(: MessageId
is
unique :)
Context: collection()
Every /FpML/header/inReplyTo must correlate to one /FpML/header/messageId. The comparison function
for correlation
is fn:deep-equal().
(: A reply must be in
response to a
message. You may not yet have the message being responded to :)
Context: collection()
Every /FpML/header/inReplyTo must not correlate to a /FpML/header/messageId in the same document. The
comparison
function for correlation is fn:deep-equal().
(: A message cannot reply to
itself. :)
Context:
collection()
Every /element(*,
MessageRejected)/header/inReplyTo must not correlate to /element(*, MessageRejected)/header/messageId. The comparison function
for correlation is fn:deep-equal().
(: If you know it is a MessageRejected message then it may not be
rejected :)
Context:
collection()
Every /element(*,
ContractCreated)/contract/header/identifier must be unique. The comparison function is ContractIdentifierEqual().
(: Contract identifiers are
unique and a
contract may only be created once :)
Context:
collection()
At least one /element(*,
ContractCancelled)/contractReference/identifier
per
document must correlate
to a /element(*,
ContractCreated)/contract/header/identifier. The
comparison function is ContractIdentifierEqual().
(: A ContractCancelled
must cancel a contract in a ContractCreated
message.
You may not yet have the ContractCreated
message. :)
Context: collection()
At least one /element(*,
ContractFullTermination)//contractReference/identifier
per
document must correlate
to a /element(*,
ContractCreated)/contract/header/identifier. The
comparison function is ContractIdentifierEqual().
(: A ContractFullTermination
must terminate a contract in a ContractCreated
message. You may not yet have the ContractCreated
message. :)
Context:
collection()
At least one /element(*,
ContractIncreased)//contractReference/identifier
per
document must correlate
to a /element(*,
ContractCreated)/contract/header/identifier. The
comparison function is ContractIdentifierEqual().
(: A ContractIncreased
must increase a contract in a ContractCreated
message. You may not yet have the ContractCreated
message. :)
Context:
collection()
At least one /element(*,
ContractNovated)//oldContractReference/identifier
per
document must correlate
to a /element(*,
ContractCreated)/contract/header/identifier. The
comparison function is ContractIdentifierEqual().
(: A ContractNovated
must novate a contract in a ContractCreated
message. You may not yet have the ContractCreated
message.
:)
Context:
collection()
At least one /element(*,
ContractPartialTermination)//contractReference/identifier
per
document must correlate
to a /element(*,
ContractCreated)/contract/header/identifier. The
comparison function is ContractIdentifierEqual().
(: A ContractPartialTermination
must partially terminate a contract in a ContractCreated
message. You may not yet have the ContractCreated
message.
:)
Context:
collection()
Every /element(*,
ContractFullTermination)/termination/contractReference/identifier
must be
unique.
(: A contract can be
terminated only once.
:)
Deprecated rules
----------------------------
IONA Technologies UK Limited (UK registered)
Registered Number: 03386680
Registered Address: 3000, Hillswood Drive, Hillswoood Business Park, Chertsey, Surrey, KT160RS, United Kingdom
|