TWIST message set Design and BusinessDocument instances (was RE: CAM templates and TWIST documents)

["Dale Moberg" <dmoberg@us.axway.com>]

[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

 

http://www.twiststandards.org/twiststandards/tiki-download_file.php?fileId=245

 

Twist uses a chameleon design, which is a way of approaching how to deal with namespaces when many schema files are involved. (I found a crisp discussion at  http://www.xfront.com/ZeroOneOrManyNamespaces.html#design )

 

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.

 

That so?