1. Business Process We all seem to agree the business process is unclear.
We all agree that people implement it incompatibly. We all agree that the
interface we define in FpML should be precisely defined. The question is
how do we make it more precise. I suggested UML STDs and CDL. Are there
any other suggestions?
2. Receipts It is arguable whether receipts are part of the business
process. Everyday transactions (depositing a cheque, buying a sandwich,
etc.), have receips. My initial proposal was to provide these
independently of the business process. i.e. you could request a receipt
for any message. Alternatively we could add the receipt to every business
process. I see receipts as a cross-cutting aspect to the business process
- it could alternatively be inlined. Either way we need something at a
more business semantic level than transport mechanism receipts such as MQ
receipts. I am open minded - but whichever choice we make we should record
and publish it.
3. Message Structure I agree with Andrew. It is a false assumption that an
entire business process lifecycle occurs in FpML. My experience is
different messages occur in different technologies - including paper and
voice. There is no need to include them in FpML. Messages are a
representation of state transfer - a transition from one state to another.
What we're missing is the graph of states connected by the transfers.
4. XML Features it seems to be a discussion for the Architecture Working
Group rather than us. I certainly wouldn't support an MS subset of XML
Schema.
Matthew Rawlings
Prime Brokerage Strategy & Architecture
+44 791 539 7824
Andrew Jacobs <andrew_jacobs@xxxxxxxxxx>
16/03/2005 12:03
Please respond to mwg
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
cc:
Subject: RE: FpML-MWG40 FpML Messaging Framework Proposal
and response to Matthew Rawling's proposed extensions
I have been following this discussion with interest and it seems to me
that several different ideas are being mixed together instead of each
being considered on its own merits.
1. The business process around amendments and cancelations is unclear. In
my experience whether an institution sees a amendment as a single thing or
as a cancellation and rebooking is normally determined by how its systems
work and how the change is detected and exported to other systems. Both
techniques achieve the same end state but with cancel and rebook is it
possible that the relationship between the two actions is lost. The same
is true of events such as option exercise.
FpML should have a preferred technique (in my opinion an amend message)
but I suspect that some firms may not be able to get away from the
cancel/rebook approach for systemtic reasons.
2. I am unclear why Matthew sees a requirement to add additional receipts.
Many transports provided this kind of information as part of thier
operation. Any if more sophistication is required then maybe he should
insert another encapsulation standard such as ebXML in his stack rather
than over complicate FpML. I need to speak to him to understand his
reasoning better.
3. Several alternative modules were considered during the design of the
messaging framework. We preferred the current approach of defining a type
of for each message because it means that the payload of each message can
be customised to suit is purpose. Whilst the approach you suggest means
that the schema does not have to be changed to add a new message type or
'action' it does entail the writing of validation code in each processor
to ensure that the content of a more generic document is appropriate to a
specific action. Using the schema to do a 'coarse' validation of the
content is an easy way of ensuring that all processing implementations get
a consistent initial level of validation.
4. Many companies involved in XML tool creation (my own included) are see
XML as a file format for persisting Java and C# languages and only support
the OO friendly features of the language. This is a big mistake. We are
trading products today using FpML that will not mature for 15-30 years.
Java and C# will be distant memories when these deals matures but the XML
will remain the legally binding contract definition.
Type substitution, complex type extension/restriction and substitution
groups are the key features of XML supporting extensibility in models.
Many of the 'opinions' on the internet regarding thier usefullness come
from people working in 'commercial' domains with more static information
models. They do not have to deal with models where products and processes
change on a regular basis. Indeed this is the problem with standards such
as ISO 20022 which are designed from the point of view of the settlement
process and centralised governance models.
Andrew Jacobs, Senior Consultant, Financial Markets
IBM UK Ltd., 76 Upper Ground, London, SE1 9PZ, UK
e-mail: andrew_jacobs@xxxxxxxxxx
Tel: +44(0)20 7202 3861 -- Fax: +44(0)20 7202 5774 -- Mobile: +44(0)7710
304239
"Ira Fuchs" <ifuchs@xxxxxxxxxxxxxxxxx>
15/03/2005 21:20
Please respond to
mwg
To <mwg@xxxxxxxxxxxxxxxxxxxxxx>
cc
Subject RE: FpML-MWG40 FpML Messaging Framework Proposal and
response to Matthew Rawling's proposed extensions
All,
To keep things lively I invite you to peruse the following regarding type
substitution. I believe that we should avoid using type substitution in
the
Message Header. I look forward to any and all comments and suggestions.
http://www.xml.com/pub/a/2003/10/29/derivation.html
http://www.xfront.com/ExtensibleContentModels.html
http://serv4.itsware.net/bb/viewtopic.php?t=671&;
http://pluralsight.com/blogs/tewald/archive/2004/08/20/1982.aspx
Ira Fuchs
XML Associates Inc.
Phone: 718-268-0592
email: <mailto:ifuchs@xxxxxxxxxxxxxxxxx> ifuchs@xxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe, e-mail: mwg-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: mwg-help@xxxxxxxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe, e-mail: mwg-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: mwg-help@xxxxxxxxxxxxxxxxxxxxxx
<<attachment: winmail.dat>>