FpML Issues Tracker
closed
Minor
Always
Architecture
Admin
andrew
Summary
Today the definition of NotificationMessage is: 1. NotificationMessage extends Message and mixes in NotificationMessageHeader. 2. Message does not contain MessageHeader. 3. NotificationMessageHeader extends MessageHeader.
I suggest instead: 1. Message contains a Message Header. 2. NotificationMessage extends Message.
The same is also true for RequestMessage and ResponseMessage. I propose the same for them also.
This would provide exactly the same XML document, but the benefit would be that the XSD would be simpler and more intuitive. A Message would now contain a MessageHeader, whereas before it never contained a MessageHeader.
This makes the type structure much simpler if you write queries using it.
Notes:
andrew
03/14/08 9:58 pm
The message header for each type message is slightly different. A request message cannot have an inReplyTo; a response message must have a inReplyTo and a notification does not have to explicit sendTo addresses.
Originally Message did contain a MessageHeader which was specialised through the use of restriction, but this was removed from the schema to make implementation easier. The only way to maintain the grammatical control over content was to move the definitions of the message header into the subtypes of Message.
With your approach the definition of the messageHeader element would again become very loose and business rules would be the only mechanism available to impose the current content constraints, but as many implementations of FpML do not rigourously check documents against the business rules this would leave systems susceptable to schema valid but semantically invalid documents.
I recommend we leave the current design as is.
matthewdr
03/17/08 8:13 am
Issue withdrawn following feedback.
The problem is that in XML Schema it is not possible to extend the contents of something other than at the root level. For example UML has property subsets and redefinitions and OWL has property inheritance by restriction, but a UML subtype can’t subset or restrict an extended property.