[snip omit CAM openers]
I think it is fine to have a CAM based way to set up the Specification content in a BusinessDocument, but I would like to also have one using schema, because the TWIST specifications use schema. So I am looking for something like:
<BusinessDocument nameID="TwistID2332" name="RequestPrice">
<ConditionExpression expressionLanguage="XPath1" expression="/Twist/@xsi:type='RequestPrice'"/>
<Specification nameID="TwistSpecification2006" name="http://www.twiststandards.org/3.1/WholesaleTrade"
location="http://unknown.org/unknown/TWIST3.1.WholesaleTrade.TwistMsgPricing.200609.xsd" type="schema" targetNamespace=“http://www.twiststandards.org/3.1/WholesaleTrade“/>
</BusinessDocument>
Now actually the Twist Message Set adheres to a particular design philosophy, and the technical basis is explained (I just discovered) in
When the topic of determining the purpose of a Twist message is developed, (all messages are in a container element “Twist”), three ways are indicated:
For effective communication, the receiver need to be able to readily determine
the nature or purpose of a given message. As part of the TWIST’s
harmonization effort with FpML The TWIST message framework is based on
type substitution as it gives the greatest control over validation while allowing
easy extension of the message elements. TWIST uses three methods to
identify a message’s purpose
Namespace
The receiver can look at the namespace from which the element definitions
have been drawn and determine the message function.
<Twist xmlns="http://www.twiststandards.org/3.0/ElectronicBilling"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<header> messageHeader</header>
Messge Data
</Twist>
Using namespaces it would be possible to create a highly extendable
framework for FpML but it could lead to documents having to have every
FpML element prefixed with a suitable namespace abbreviation although it
may be possible to mitigate this by having the 'core' sub-schemas use no
namespaces in their definition and take on the namespace of the one they are
including into. There may be further issues with related XML standards such
as XPath as the namespace of the same included elements may not be
consistent between documents.
messageType Element Value
The receiver can look at the name associated with an optional element
‘messageType’ within the message to determine the function requested.
<Twist xmlns="http://www.twiststandards.org/3.0/Payments"
xmlns:isth="urn:swift:xsd:$pain.001.001.01"
xmlns:isthdd="urn:swift:xsd:$pain.001.001.01.dd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<header>
<messageType>RemittanceAdvice</messageType>
</header>
Message Data
</Twist>
Element Type
The receiver can look at the xsi:type attribute associated with the root element within
the message
<Twist xmlns="TWIST3.0.FinancialSupplyChain.TWISTMsgSupplyChain.200606.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type=”Invoice”>
<header>
message header
</header>
Message Data
</Twist>
An XML schema based instance document may use type substitution to
replace the content model of any element with another providing that the
replacement is derived from the original. Given a framework that provides the
appropriate extension points any number of new types can be derived within
the name or different namespaces as necessary. In addition through
inheritance the message types can be associated with an appropriate
message header content model.
Now, since the namespace does not seem to me to really identify the message distinctively and since the MessageType element is optional, it seems best to make use of the xsi:type attribute’s value.
So I think that the xsi:type value check is probably the best identifier, and this mechanism aligns with CAM option below:
4) Alternatively you can make the linkage here dynamic - so either the XPath to a structure item can be checked to test which structure instance is being transacted ( therefore external parameters not needed) - or the CAM template can be directly associated by the XML instance.